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ЧАСТЬ 


Введение 
в АЗРМЕТ МУС 


| овая платформа АЗРМЕТ МУС обеспечила радикальный сдвиг в разработ- 
ке веб-приложений на платформе Месгозон. В ней делается упор на ясную 
архитектуру, шаблоны проектирования и тестируемость. Первая часть книги 
призвана помочь разобраться в фундаментальных идеях, положенных в основу 
АЗРМЕТ МУС, и ознакомиться с практическим применением этой платформы. 


ГЛАВА | 


Основная идея 


А\з“= МУС — это платформа для веб-разработки от М!сгозой, которая сочетает 
в себе эффективность и аккуратность архитектуры “модель-представление-кон- 
троллер” (поае!-ммехи-сопегоПег — МУС), новейшие идеи и приемы гибкой разработки, 
а также все лучшее из существующей платформы АЗР.МЕТ. Это полная альтернатива 
традиционной технике АЗРМЕТ \е БЕ опт$, предлагающая существенные преимущества 
для всех, кроме самых тривиальных проектов веб-разработки. 


Краткая история веб-разработки 


Чтобы понять отличительные аспекты и цели проектирования АЗРМЕТ МУС, стоит 
хотя бы кратко напомнить, как шило развитие веб-разработки до сих пор. Совершенст- 
вование всех платформ веб-разработки М1сгозой. которое мы наблюдали в течение 
последних лет, сопровождалось постоянным ростом мощности и (к сожалению), слож- 
ности. Как показано в табл. 1.1, каждая новая платформа устраняла специфические 
недостатки своей предшественницы. 


Таблица 1.1. Хронология технологий веб-разработки Мюсгозо_ 


Период времени | Технология Достоинства Недостатки 


Выполняется вне веб-сервера, 

Простота поэтому является ресурсоемкой 

Соттоп Саемау Гибкость (порождает по одному отдельно- 

мегасе (СС|)° Единственный му процессу операционной систе- 
выбор на то время мы на каждый запрос) 

Является низкоуровневой 


Является лишь оболочкой для за- 
просов СЁ и шаблонов для форма- 
тирования результирующего набора 


Интерпретируется во время 


Юрский период 


Мегозо Ищете! 


Ра{аБазе Соппесюог Выполняется внутри 


Бронзовый век ие веб-сервера 


1996 г. Асвуе Зегуег Радез Общее назначение и 
(АБР) Приводит к появлению 
“спагетти-кода” 
2002/2003 гг. АЗРМЕТ 1.0/1.1 Компилируемый пользова- <. 
тельский интерфейс с под- Требует большой ширины 
2005 г АЗРМЕТ 2.0 держкой состояния а, 
Обширная инфраструктура Порождает корявую НТМЕ- 
зме 
РО МЕТАНА Стимулирует объектно- а 
ориентированное р 
2008 Г АСРМЕТЗ.5 программирование Не является тестируемой 


* СС! — стандартное средство подключения веб-сервера к произвольной исполняемой программе, которая воз- 
вращает динамическое содержимое. Спецификация поддерживается МСЗА (Майопа! Сегцег Тог Зирегсотрийпо 
Аррйса#от$ — Национальный центром приложений для суперкомпьютеров). 
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Аналогично АЗР.МЕТ МУС устраняет специфические недостатки традиционной плат- 
формы АЗРМЕТ \еБЕогииз, но на этот в направлении упрощения. 


Традиционная платформа АЗР.МЕТ 


На момент своего появления АЗРМЕТ стала огромным шагом вперед в разработке, 
причем не только благодаря использованию совершенно новой многоязыковой плат- 
формы управляемого кода „МЕТ (которая и сама по себе была значительной вехой), но 
и потому, что ее предназначением было заполнение пробела между основанной на со- 
стоянии объектно-ориентированной разработкой \Лпаолуз Еогтз и не поддерживающей 
состояние, ориентированной на язык НТМГ. веб-разработкой. 

М!сгозой попыталась сокрыть как протокол НЛТР (с его неизбежным отсутствием 
состояния), так и язык НТМТ. (который на тот момент был незнаком многим разработ- 
чикам), моделируя пользовательский интерфейс, как находящуюся на сервере иерар- 
хию объектов — элементов управления. Каждый такой элемент управления отслежи- 
вает свое собственное состояние между запросами (с помощью средства Ме ае), по 
мере необходимости автоматически визуализируя себя в виде НТМЕ-разметки, и авто- 
матически подключая события клиентской стороны (например, щелчки на кнопках) с 
соответствующим кодом их обработки на стороне сервера. Фактически \МеБЕогиз — это 
гигантский уровень абстракции, предназначенный для воссоздания классического, 
управляемого событиями графического пользовательского интерфейса в веб-среде. 

Отныне разработчикам не нужно иметь дело с сериями независимых запросов и от- 
ветов НТТР, как это делалось в старых технологиях; теперь можно думать в терминах 
пользовательского интерфейса, сохраняющего свое состояние. Мы можем “забыть” о 
веб-среде и строить пользовательские интерфейсы в интерактивном редакторе с функ- 
циями перетаскивания. предполагая, что все это будет происходить на сервере. 


Недостатки традиционной платформы А$Р.МЕТ 


Технология АЗРМЕТ была замечательной и поначалу казалась прямой дорогой в 
светлое будущее, но, разумеется, в реальности все было несколько сложнее. За годы ис- 
пользования \еБ Роги проявились слабые стороны. 


® УеихУсе. Реализованный механизм поддержки состояния между запросами 
(Лема) часто требовал передачи огромных блоков данных между клиентом 
и сервером. В реальных приложениях этот объем нередко достигал сотен кило- 
байт, которые ходили вперед и назад с каждым запросом, вызывая раздражение 
у посетителей сайтов из-за длительного ожидания реакции на каждый щелчок на 
кнопке или попытку перехода на следующую страницу в большой таблице. В той 
же мере страдала от этого! и платформа АЗРМЕТ ААХ, даже несмотря на то, что 
посредством Адах планировалось как раз и решить проблему объемного трафика, 
связанный с полным обновлением страницы. 


® Жизненный цикл страницы. Механизм подключения событий клиентской сторо- 
ны к коду обработчинков событий на стороне сервера, как часть жизненного цикла 
страницы, мог быть чрезвычайно сложным и хрупким. Очень немногим разра- 
ботчикам удавалось успешно манипулировать иерархией элементов управления 
во время выполнения, избегая опгибок Леа или не сталкиваясь с ситуацией, 
когда некоторые обработчики событий совершенно загадочным образом отказы- 
вались работать. 


3 При каждом асинхронном запросе должны были отправляться данные \емфаЕе для полной 
страницы. 
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® Ограниченный контроль над НТМГ-разметкой. Серверные элементы управления 
визуализируют себя в виде НТМЕ-разметки, но не обязательно в виде того кода 
НУМЕ, который вам нужен. Получаемый в резульгате код НТМГ нередко не от- 
вечает требованиям веб-стандартов и не использует С$$, а система серверных 
элементов управления генерирует непредсказуемые и сложные значения иденти- 
фикаторов, с которыми трудно работать в ЧауаЗсир*-коде. 


® Ложное чувство разделения ответственности. Модель отделенного кода (соде- 
Берта) АЗРМЕТ предоставляет средства вынесения прикладного кода из НТМТ- 
разметки в файл отделенного кода. Это отвечает широко принятому принципу 
разделения логики и представления, но на самом деле разработчикам приходи- 
лось смешивать код представления (например, манипуляцию деревом элементов 
управления серверной стороны) с логикой приложения (например, манипуляцию 
информацией из базы данных) в одном монстроподобных классах отделенного 
кода. Без более четкого разделения ответственности конечный результат зачас- 
тую получался хрупким и непредсказуемым. 


® Невозможность тестирования. Когда проектировщики АЗРМЕТ создавали свою 
платформу, они не могли предвидеть, что автоматизированное тестирование ста- 
нет неотъемлемой частью современной разработки программного обеспечения. 
Не удивительно, что спроектированная ими архитектура совершенно не приспо- 
соблена для автоматизированного тестирования. 


Платформа АЗРМЕТ двигалась вперед. В версию 2.0 был добавлен набор стандарт- 
ных компонентов приложений, существенно сокративших объем кода, который нужно 
было писать самостоятельно. Выход Адах в 2007 г. стал ответом М1сгозой на “сенсацию 
дня” — \2.0/Адах, поддерживающую развитую интерактивность клиентской стороны 
и при этом упрощающую разработчику жизнь”. Самая последняя версия 3.5 включает 
менее значительные дополнения; в ней появилась поддержка средств .МЕТ 3.5 и набора. 
новых элементов управления. Новое средство динамических данных АЗРМЕТ (Рупапис 
Ра{а) позволяет автоматически генерировать простые экраны просмотра/редактирова- 
ния базы данных. В очередной версии АЗРМЕТ 4.0, которая должна поставляться вместе 
с \15ца| Зоо 2010, разработчикам будет предложена возможность явного управления 
идентификаторами определенных НТМГ-элементов, что должно сократить проблему по- 
явления непредсказуемых и сложных значений для идентификаторов. 


Веб-разработка сегодня 


За пределами Мсгозой со времен появления \еБЕогтз технологии веб-разработки 
быстро развивались в нескольких разных направлениях. Помимо уже упомянутого Адах 
произотило и несколько других прорывов. 


Веб-стандарты и ВЕЗТ 


Движение за соблюдение веб-стандартов в последние годы не утихало, а наоборот — 
усиливалось. Веб-сайты просматриваются большгим разнообразием устройств и брау- 
зеров, чем когда-либо ранее, и веб-стандарты (НТМГ, С$5$, дауазспрЕ и т.п.) позволяют 
надеяться на единообразное представление информации повсеместно (вплоть до под- 
ключенных к Интернету холодильников}. 


? По иронии судьбы объект ХМЬНЕЕрВедиез{ — основу технологии Адах — изобрели именно 
в М!сгозой, для поддержки ОиНоок УЪ Ассез$. Однако почему-то его потенциал не был вос- 
требован до тех пор, пока это не сделали сотни других компаний. 
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Современные веб-платформы не могут игнорировать потребностей бизнеса и энту- 
зиазма разработчиков, нацеленных на соблюдение веб-стандартов. 

В это же время невероятную популярность в качестве архитектуры взаимодейст- 
вия приложений через НЛТР завоевала ВЕЗТЗ; особенно это касается информационной 
смеси мира \еЪ 2.0. Поскольку теперь доступны развитые клиенты Адах и ЭПуе +, 
различия между веб-службами и веб-приложениями постепенно размываются, и в та- 
ких сценариях КЕЗТ превалирует над ЗОАР. Архитектура ВЕЗТ требует такого подхода 
к обработке НТТР и ОБТ, который в традиционном АЗРМЕТ не поддерживается. 


Гибкая разработка и разработка, управляемая тестами 


За последнее десятилетие шаг вперед сделала не только веб-разработка — разра- 
ботка программного обеспечения в целом также не стояла на месте; здесь произошел 
сдвиг в сторону гибких (а51е) методологий. Для разных людей “гибкость” несет в себе 
множество различных значений, но в основном оно касается организации проектов по 
разработке программного обеспечения в форме адаптируемых процессов исследования, 
противостояния затруднениям, вызванным чрезмерной бюрократизацией, и ограни- 
ченным опережающим планированием. Энтузиазму, сопровождающему гибкие методо- 
логии, сопутствует энтузиазм применения определенных приемов и инструментов раз- 
работки — обычно с открытым исходным кодом, — который стимулирует и помогает 
их применению. 

Очевидным примером является разработка, управляемая тестами ((е5Е-апуеп 
Чехеюортепе — ТОО) — когда разработчики повышают собственную способность реа- 
гировать на изменения без нарушения стабильности своей кодовой базы, потому 
что каждое известное и желаемое поведение уже зафиксировано в десятках, сотнях 
или тысячах автоматизированных тестов, которые можно прогнать в любой момент. 
Недостатка в инструментах МЕТ, поддерживающих автоматизированное тестирова- 
ние, нет, но они могут применяться эффективно лищь к программному обеспечению, 
которое спроектировано в виде набора четко отделенных друг от друга независимых 
модулей. К сожалению, типичное приложение \еЬКогтз подобным образом описать 
не получится. 

Сообщество независимых поставщиков программного обеспечения (паерепаеп+ 
эоймгаге успаог — Т5У) вместе с сообществом открытого кода разработали множество 
высококачественных каркасов для модульного тестирования (МОрИ, МВИп), имитации 
(Кышло Москз, Мод), контейнеров инверсии управления (Сазйе УЯпазог, Зргиля.МЕТ), сер- 
веров непрерывной интеграции (Сгзе Сопйёго!, Теа СНУ}, средств объектно-реляцион- 
ного отображения (МНеглае, 5550116) и ти. Сторонники этих инструментов и прие- 
мов даже выработали общий язык, издают публикации и проводят конференции под 
общей маркой АГТ.МЕТ. Вследствие своего монолитного дизайна традиционная техноло- 
гия АЗРМЕТ \'еБЕогиа$ не слишком подходит для таких инструментов и приемов, поэто- 


му со стороны этой шумной группы экспертов и лидеров индустрии АЗРМЕТ \еБЕогь 
уважением не пользуется. 


ы Архитектура ВЕЗТ (ВергезепюнНопа $кие Тгапз}ег — передача состояния представления) 
описывает приложение в терминах ресурсов (ЧК, представляющих сущности реального 
мира, и стандартных операций (методов НТТР), представляющих доступные операции над 
этими ресурсами. Например, можно выполнить операцию РОТ для нового ресурса Веер: // 
"ги. ехатр1е. сом/Ргодасе$/Ъампмомег или операцию РЕТЕТЕ в отношении сущест- 
вующего ресурса Вер: //мии.ехапр1е .сом/Сазкотегз/Ахгпо19-5и4ен. 
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ВиБу оп Вай$ 


В 2004 г. ВыБу оп Ка|$ был тихим, незаметным продуктом с открытым исходным 
кодом от неизвестного игрока. Но неожиданно он достиг славы, изменив правила веб- 
разработки. Сам по себе он не представлял особо революционной технологии. а просто 
взял существующие ингредиенты и приготовил из них чудесный, волшебный, велико- 
лепный способ пристыдить существующие платформы. 

Применение архитектуры МУС (известного шаблона проектирования, в последнее 
время заново “открытого” многими веб-каркасами), работа в гармонии с протоколом 
НТТЬ, внедрение соглашений вместо обязательного конфигурирования и интеграция 
инструмента объектно-реляционного отображения (ОБМ) в ядро позволило приложе- 
ниям ВаП$ завоевать популярность без особых усилий или затрат. Это было похоже на 
открытие того. каковой должна быть веб-разработка: мы вдруг осознали, что все эти 
годы боролись с нашими инструментами, и вот — война окончена. 

Продукт Кай$ доказал, что соблюдение веб-стандартов и соответствие ВЕЗТ не обя- 
зательно должно быть трудным. Он также продемонстрировал, что гибкая и управляе- 
мая тестами разработка внедряется легко, если сам каркас спроектирован для се под- 
держки. Остальной мир веб-разработки немедленно подхватил идею. 


Ключевые преимущества АЗР.МЕТ МУС 


Громадные корпорации вроде М1сгозой. могут подолгу почивать на лаврах, но вечно 
это продолжаться не может. Платформа АЗРМЕТ имела огромный коммерческий успех, 
но как было сказано, остальная часть мира веб-разработки не стояла на месте. и не- 
смотря на то, что Масгозой. продолжала распространять \еЕогиз, ее дизайн выглядел 
все более устаревающим. 

В октябре 2007 г. на самой первой конференции АЕТ.МЕТ в Остине, шт; Техас, вице- 
президент Мсгозой Скотт Гатри (Зсой Сие) продемонстрировал совершенно новую 
платформу веб-разработки МУС, построенную на базе АЗРМЕТ, четко спроектирован- 
ную как прямой ответ на звучавшую ранее критику. Именно она позволила преодолеть 
ограничения АЗРМЕТ и вновь вывести платформу Мсгозой на передний край. 


Архитектура “модель-представление-контроллер” 


Благодаря адаптации к архитектуре МУС, платформа АЗЬМЕТ МУС предлагает зна- 
чительно улучнтенное разделение ответственности. Шаблон проектирования МУС не 
нов — его истоки восходят еще к 1978 г и проекту ЗтаШаК, разработанному в Хегох 
РАКБС. Но именно сегодня он завоевал невероятную популярность в качестве архитекту- 
ры веб-приложений. Причины этого, скорее всего, состояли в следующем. 


® Взаимодействие пользователя с приложением МУС естественным образом следу- 
ет циклу: пользователь предпринимает действие, в ответ на которое приложение 
изменяет свою модель данных и доставляет измененное представление пользова- 
телю. Затем цикл повторяется. Это очень удобно укладывается в схему веб-прило- 
жений, состоящих из последовательностей запросов и ответов НТТР. 


® Веб-приложения, нуждающиеся в комбинации нескольких технологий (например, 
баз данных, НТМГ. и исполняемого кода), обычно разделяются на ряд уровней, и 
получающийся в резульгате шаблон естественным образом отображается на кон- 
цепцию МУС. 
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В АЗРМЕТ МУС реализован современный вариант МУС, который особенно подходит 
для веб-приложений. В главе 3 можно найти дополнительные сведения о теории и прак- 
тике, связанной с этой архитектурой. 

Благодаря своему дизайну, АЗРМЕТ МУС может напрямую конкурировать с КиБу 
оп КаП$ и подобными платформами, привнося этот стиль разработки в основной поток 
мира „МЕТ, и опираясь на опыт и практические приемы, открытые разработчиками на 
других платформах, во многом даже опережая все то, что может предложить КиБу: 


Расширяемость 


Внутренние компоненты настольного компьютера являются независимыми частя- 
ми, которые взаимодействуют только по стандартным, публично документированным 
интерфейсам. Это позволяет легко заменять практически любой компонент — скажем, 
плату графического адаптера или жесткий диск — аналогичным, но от другого произ- 
водителя, имея при этом гарантию, что он подойдет, и будет нормально работать. Точно 
так же и платформа МУС построена в виде серии независимых компонентов — реали- 
зующих интерфейс „МЕТ или построенных на основе абстрактного базового класса, — 
поэтому можно легко заменить систему маршрутизации, механизм представлений, фаб- 
рику контроллеров или прочие компоненты платформы другими, с вашей оригинальной 
реализацией. Фактически разработчики платформы в отношении каждого компонента 
МУС Егате\хюогК предлагают три варианта. 


1. Использование стандартной (по умолчанию) реализации компонента в том виде, 
как она есть (этого вполне достаточно для большинства приложений). 


2. Порождение подкласса от стандартной реализации с целью корректировки суще- 
ствующего поведения. 


3. Полная замена компонента новой реализацией интерфейса или абстрактного ба- 
зового класса. 


Это похоже на модель поставщиков (Рго\14ег) из АЗРМЕТ 2.0, но пускающую корни 
намного глубже — прямо в сердце платформы МУС. Различные компоненты вместе с 
причинами возможной их корректировки или замены будут рассматриваться, начиная 
с главы 7. 


Тестируемость 


Естественное разнесение различных сущностей приложения по разным, незави- 
симым друг от друга частям программного обеспечения, которое поддерживает ар- 
хитектура МУС, позволяет уже изначально строить сопровождаемые и тестируемые 
приложения. 

Однако проектировщики АЗРМЕТ МУС на этом не остановились. Для каждого фраг- 
мента компонентно-ориентированного дизайна платформы они обеспечили идеальную 
структурированность для автоматизированного тестирования. В результате появилась 
возможность писать ясные и простые модульные тесты для каждого контроллера и дей- 
ствия разрабатываемого приложения, используя фиктивные или имитирующие реали- 
зации компонентов каркаса для эмуляции любого сценария. В дизайне обеспечен об- 
ход ограничений современных инструментов тестирования и имитации. В среду \1виа! 
Эёл@ю добавлен набор мастеров для создания стартовых тестовых проектов (интегриро- 
ванных с такими инструментами модульного тестирования с открытым кодом, как МОпИ 
и МВОПЬ, а также М1сгозой М$Тез9, которые помогают тем, кому писать модульные тес- 
ты ранее не доводилось. Словом, добро пожаловать в мир сопровождаемого кода! 


26 — Часть |. Введение в АЗРМЕТ МУС 


На протяжении всей книги будут приводиться примеры того, как следует писать 
автоматизированные тесты с использованием различных стратегий тестирования и 
имитации. 


Жесткий контроль над НТМЕ 


В МУС учтена важность генерации ясного и соответствующего стандартам кода 
разметки. Разумеется, встроенные вспомогательные методы НТМГ, генерируют ХНТМЕ- 
совместимый вывод, однако необходимо принять существенный сдвиг в образе мышле- 
ния. Вместо громадного объема трудночитаемого НТМГ-кода, представляющего простые 
элементы пользовательского интерфейса, наподобие списков, таблиц или строковых ли- 
тералов, архитектура МУС стимулирует создание простых и элегантных, стилизован- 
ных с помощью С55 компонентов. (Вдобавок, массивная поддержка рефакторинга С55 
в среде \1зиа1 За 2008, наконец, обеспечила возможность отслеживания и повтор- 
ного использования правил С5$5, причем независимо от размеров проекта.) 

Реализованный в АЗРМЕТ МУС подход к разметке в стиле “специальные требования 
отсутствуют” облегчает использование лучших библиотек пользовательского интерфей- 
са с открытым кодом, таких как |Очету или УаВоо ОТ 14гагу; это необходимо для рабо- 
ты с готовыми элементами пользовательского интерфейса, подобными календарям или 
каскадным меню. В главе 12 будет продемонстрировано немало подобных приемов, по- 
зволяющих с минимальными усилиями получить развитую и не зависящую от браузера. 
интерактивность. Разработчики дауа сир будут приятно удивлены, узнав, что попу- 
лярная библиотека |Очегу не только эффективно поддерживается, но даже поставляет- 
ся как встроенная часть шаблона проекта АЗРМЕТ МУС по умолчанию. 

Стенерированные АЗРМЕТ МУС страницы не содержат никаких данных Уем5 ее, 
поэтому они могут быть на сотни килобайт меныше типичных страниц АЗРМЕТ 
МеБЕогт5. Несмотря на современные скоростные широкополосные соединения, такая 
экономия трафика невероятно повышает комфорт конечного пользователя. 


Мощная новая система маршрутизации 


Современные веб-разработчики осознают важность использования чистых ЧВТ- 
адресов. Малопонятные ОВГ-адреса вроде /Арр_у2/Чзек/Раде .азрх?асЕ1оп=5рои%20 
ргор&ёргор 19=82742 вряд ли полезны, а вот /ко-гепЕ/сВ1садо/2303-511уех-зЕгеее 
выглядит намного профессиональнее. Почему это важно? Во-первых, механизмы поис- 
ка придают ключевым словам, содержащимся в ОБТ, больший вес. Поиск по фрагменту 
“гепе ш сЫсаряо” (жилье в Чикаго) с большей вероятность обнаружит последний из при- 
веденных ОБТ, а не первый. Во-вторых, многие веб-браузеры достаточно сообразитель- 
ны, чтобы понять ОБТ, и предоставляют возможности навигации во время их ввода в 
поле адреса. В-третьих, когда кто-то чувствует, что может понять ОВГ, он с болыпей 
вероятностью обратится к нему (будучи уверенным, что его персональная информация 
останется в безопасности) или поделится им с друзьями (например, продиктовав по 
телефону). В-четвертых, в чистых ОВ! не раскрываются лишние технические детали, 
структура каталогов и имен файлов приложения (и вы вольны изменять лежащую в ос- 
нове сайта реализацию, не нарушая работоспособности входящих ссылок). 

На ранних платформах чистые ОВГ-адреса реализовать было трудно. АЗРМЕТ МУС 
предлагает совершенно новое средство бузеен.иер.БочЕ1та, по умолчанию обеспечи- 
вающее чистыми ОВГ-адресами. Это предоставляет полный контроль над схемой ОВ! и 
ее отображением на контроллеры и действия — без необходимости соблюдения какого- 
то предопределенного шаблона. Это также означает возможность простого определения 
современной схемы ОВТ, в стиле ВЕЗТ, если есть к тому склонность. 
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За полным описанием маршрутизации и полезными советами относительно ОВГ, об- 
ращайтесь в главу 8. 


Построение на основе лучших частей платформы А$Р.МЕТ 


Существующие платформы Мсгозой предлагают зрелый, проверенный набор ком- 
понентов и средств, которые могут значительно облегчить вашу ношу и расширить 
свободу. Первое, и наиболее очевидное — поскольку АЗРМЕТ МУС базируется на плат- 
форме „МЕТ 3.5, вы вольны писать код на любом языке МЕТ“. При этом доступны не 
только средства, с которыми работает МУС, но и все богатые возможности библиотеки 
базовых классов МЕТ, а также широкого разнообразия библиотек .МЕТ от независимых 
разработчиков. 

Готовые средства платформы АЗРМЕТ, такие как мастер-страницы, аутентифика- 
ция с помощью форм, членство, роли, профили и глобализация, могут существенно 
сократить объем кода, который придется разрабатывать и поддерживать в любом веб- 
приложении, и в проекте МУС это столь же эффективно, как и в классическом проекте 
УеБЕогтз. В приложении АЗРМЕТ МУС могут повторно использоваться некоторые сер- 
верные элементы управления \еБРогтпз, а также специальные элементы управления из 
прежних проектов АЗРМЕТ (если только они не зависят от специфической для \ебЕогте 
нотации — вроде Мела). 

Вопросы разработки и развертывания также решены. Платформа АЗРМЕТ хорошо 
интегрирована в У1зиа] 56а 1ю — ведущую коммерческую ШЕ-среду от М!сгозой. Вдобавок 
эта “родная” технология веб-программирования поддерживается веб-сервером Н$, 
входящим в состав операционных систем \Ипаохуз ХР, \Явца, 7 и Зегуег В версии П$ 7.0 
появился набор расширенных средств для выполнения управляемого кода .МЕТ как 
части конвейера обработки запросов; это предоставляет приложениям АЗРМЕТ специ- 
альные возможности. Ностроенные на базе ядра платформы АЗРМЕТ, приложения МУС 
разделяют все ее преимущества. 

В главе 14 объясняется все, что следует знать о развертывании приложений АЗРМЕТ 
МУС на сервере П$ в среде УЛпаохуз Зегуег 2003 и \Япао\уз Зегуег 2008. В главе 16 де- 
монстрируются основные средства платформы АЗРМЕТ, которые, скорее всего. будут 
использоваться в приложениях МУС, показана разница в применении приложений МУС 
и \еБЕони®, а также приведен ряд советов и подсказок по преодолению проблем совмес- 
тимости. Даже эксперты в АЗРМЕТ могут обнаружить там пару полезных компонентов, 
которыми не пользовались ранее. 


Языковые нововведения в .МЕТ 3.5 


С момента своего появления в 2002 г. платформа Мусгозой .МЕТ значительно эво- 
люционировала, поддерживая и даже определяя многие искусные аспекты современно- 
го программирования. Наиболее существенным из последних новшеств является ЕАМ 
(Гапдиаде пивогсйеа Оиегу — язык интегрированных запросов), а также целое множе- 
ство дополнительных расширений языка С#, таких как лямбда-выражения и аноним- 
ные типы. Платформа АЗРМЕТ МУС спроектирована с учетом этих нововведений, по- 
этому многие из методов ев АР-интерфейса и шаблонов кодирования следуют более 
ясной и выразительной композиции, чем это было возможно в ранних реализациях 
платформы. 


* Можно даже строить приложения АЗРМЕТ МУС на НопКиЪу или ПопРуоп, хотя большин- 
ство заказчиков на данный момент отдают предпочтение С# и УВ.МЕТ. В зтой кните внима- 
ние сосредоточено исключительно на С#. 
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АЗР.МЕТ МУ\УС — продукт с открытым кодом 


Столкнувшись с конкуренцией со стороны альтернативных продуктов с открытым 
кодом, в Масгозой решились на храбрый шаг в отношении АЗРМЕТ МУС. В отличие 
от многих прежних платформ веб-разработки МасгозоЙ_, оригинальный исходный код 
АЗР.МЕТ МУС доступен для свободной загрузки. После этого его можно модифицировать 
и построить собственную версию. Это неоценимо в ситуациях, когда во время отладки 
необходимо пройтись по коду какого-то системного компонента (и даже читать ориги- 
нальные комментарии программиста), либо при построении расптиренного компонента. 
посмотреть, какие доступны возможности разработки, либо просто разобраться, как в 
действительности функционируют встроенные компоненты. 

Упомянутая возможность также полезна и тогда, когда не устраивает работа того 
или иного компонента, когда требуется найти ошибку или когда необходимо получить 
доступ к тому. что с помощью иных способов не доступно. Однако при этом необходимо 
отслеживать все внесенные изменения и повторять их после перехода на более новую 
версию каркаса. Здесь на помощь придет какая-нибудь система управления версиями. 

АЗРМЕТ МУС лицензируется в соответствии с условиями М$-Р1. (ими .орепзопгсе. 
0г9/11сепзез/мз-р1.НЕт1) — утвержденной ОЗ лицензии открытого кода. Это зна- 
чит; что исходный код можно изменять, развертывать и даже распространять публич- 
но в виде производного проекта. Следует отметить, что на данный момент Мисгозой не 
принимает заплаты в отношении центральной, официальной сборки. Мсгозой толь- 
ко поставляет код, созданный собственными командами разработчиков и контроля 
качества. 

Исходный код АЗРМЕТ МУС доступен для загрузки по адресу БЕЕр: //Е1пуик1 . сом/ 
с5313п. 


Пользователи АЗР.МЕТ МУС 


Как и с любой другой технологией, простой факт ее существования еще не является 
основанием для ее обязательного внедрения (несмотря на естественное желание неко- 
торых разработчиков попробовать что-то новое). Давайте сравним платформу МУС с 
наиболее очевидными альгернативами. 


Сравнение с АЗР.МЕТ Ме Рогт$ 


Вы наверняка уже слышали о недостатках и ограничениях, присущих традицион- 
ной технологии АЗРМЕТ \еБГЕоги®, и о том, что АЗРМЕТ МУС решает многие из этих 
проблем. Тем не менее, это не значит, что \\е Копп можно списывать со счетов — в 
М1сгозой не перестают напоминать, что эти две платформы идут рука об руку, поддер- 
живаются в равной мере, и обе являются субъектами активной, непрерывной разра- 
ботки. Во многих отношениях выбор между ними двумя является вопросом философии 
разработки, которая вам ближе. 


® Философия \еБЕогтз исходит из представления, что пользовательский интер- 
фейс обладает состоянием. Для этого поверх НТТР и НТМ1Т. добавляется изощрен- 
ный уровень абстракции, а для создания эффекта сохраненного состояния ис- 
пользуются концепции Леха и обратных отправок. Такой подход хорош для 
визуальной разработки в стиле \УЯпао\з Еоги®, когда на рабочую поверхность по- 
мещаются виджеты (графические элементы) пользовательского интерфейса, а их 
обработчики событий заполняются соответствующим кодом. 
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® Философия МУС подчеркивает естественную особенность протокола НТТР, свя- 
занную с отсутствием поддержки состояния, и вместо того, чтобы преодолевать, 
приспосабливается к ней. Хотя это требует действительного понимания работы 
веб-приложений, но одновременно предоставляет простой, мощный и современ- 
ный подход к написанию веб-приложений с аккуратным кодом, который легко 
тестировать и сопровождать, кодом. свободным от причудливых сложностей и 
болезненных ограничений. 


Бывают определенные случаи, когда \МеЪКогиз оказывается, по крайней мере, не 
хуже, а может быть, и лучше, чем МУС. Очевидный пример — небольшие, ориентиро- 
ванные на внутреннюю корпоративную сеть, приложения, которые в основном напря- 
мую связывают сетки данных (619) с таблицами базы данных либо проводят пользова- 
телей по ряду страниц мастера (х1еага). Поскольку при этом не нужно беспокоиться о 
проблемах пропускной способности, связанных с передачей ем еце, об оптимизации 
поисковых механизмов, о тестируемости и долгосрочном сопровождении, достоинства 
разработки методом перетаскивания перевешивают ее недостатки. 

С другой стороны, если вы пишете приложение для публичного доступа через 
Интернет или крупные внутрикорпоративные приложения (требующие свыше несколь- 
ких человеко-месяцев работы}; если вы нацелены на высокую скорость загрузки и со- 
вместимость с множеством браузеров; если требуется построить высококачественный 
код на основе продуманной архитектуры, подходящий для автоматизированного тести- 
рования, то в таких ситуациях МУС обладает существенными преимуществами. 


Переход от ИеБРогт$ к МУС 


В одном и том же приложении допускается сосуществование АЗРМЕТ и МУС. Это 
значит, что перенос на платформу МУС разрабатываемого приложения АЗРМЕТ можно 
выполнять постепенно, что особенно важно, если оно уже разделено на уровни в соот- 
ветствии с моделью предметной области или если бизнес-логика отделена от страниц 
УеБЕогтз. В некоторых случаях приложение можно проектировать как гибрид двух тех- 
нологий. Все эти вопросы рассматриваются в главе 16. 


Сравнение с ВиБу оп Вай$ 


Кай превратился в своего рода образец, с которым следует сравнивать другие веб- 
платформы. Суровая реальность состоит в том, что разработчики и компании, рабо- 
тающие в мире М!сгозоЁ_ „МЕТ, сочтут более простой в адаптации и изучении платфор- 
му АЗРМЕТ МУС, в то время как компании, работающие на Руоп или ВиБу в Ипах 
и Мас ОЗ Х, отдадут предпочтение КаЙз. Маловероятно, что понадобится выполнять 
переход от КаЙ5 на АЗРМЕТ МУС или наоборот. Между этими двумя технологиями су- 
ществуют значительные различия в области применения. 

КаИ8 — это полностью целостная платформа разработки, в том смысле, что она ох- 
ватывает весь стек — от управления исходными базами данных (миграциями) до объ- 
ектно-реляционного отображения (ОБМ), обработки запросов с помощью контроллеров 
и действий, а также построения автоматизированных тестов. В общем, Байз представ- 
ляет собой самодостаточную систему быстрой разработки приложений, ориентирован- 
ных на данные. 

В противоположность этому, платформа АЗРМЕТ МУС сосредоточена исключитель- 
но на задаче обработки веб-запросов в стиле МУС с помощью контроллеров и действий. 
Она не имеет ни встроенного инструмента ОБМ, ни встроенного инструмента модуль- 
ного тестирования, ни системы управления миграциями баз данных — все это, а также 
многое другое предлагает платформа .МЕТ, и вам останется только сделать выбор. 
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Например, в качестве инструмента ОКМ можно использовать МНФегпае, М1сгозой. 
ГМО 0 ОГ, иБзошс или любое из других зрелых решений. В этом и состоит роскошь 
платформы „МЕТ, хотя это также означает, что упомянутые компоненты не могут быть 
настолько тесно интегрированы с АЗРМЕТ МУС, как их эквиваленты в Кай$. 


Сравнение с МопоВай 


Вплоть до настоящего момента ведущей платформой веб-разработки на основе МЕТ 
МУС была система СазЙе МопоКаП — составная часть проекта Саз@е с открытым ис- 
ходным кодом, разрабатываемого с 2003 г Если вы имели дело с МопоКа1, то АЗРМЕТ 
МУС покажется знакомым; обе технологии основаны на ядре платформы АЗРМЕТ, и обе 
в значительной мере вдохновлены КиБу оп Кай. Они используют одинаковую термино- 
логию во многих местах (основатели МопоКа] участвовали в процессе проектирования 
АЗРМЕТ МУС}, и привлекают внимание одних и тех же разработчиков. Тем не менее, 
между ними есть и различия. 


® МопоКай может работать на платформе АЗРМЕТ 2.0, в то время как АЗРМЕТ МУС 
требует версии АЗРМЕТ 3.5. 


® В отличие от АЗРМЕТ МУС, в МопоВай предпочтение отдается одной конкрет- 
ной реализации ОКМ. В случае использования СазИе АсНуеВесога (основанной 
на МНфегпа), МопоВай может генерировать базовый код для просмотра и ввода 
данных автоматически. 


® МопоКай очень похожа на ВКиБу оп Вайз. В дополнении к использованию Кай$- 
подобной терминологии (групповая запись и чтение, восстановление данных, 
компоновки и т.п.) ужесточается значение проектирования по соглашениям. 
В приложениям МопоВа! часто используется одна и та же стандартная схема ЧВЬ 
(/контроллер/действие). 


® В МопоКай нет прямого аналога системы маршрутизации АЗРМЕТ МУС. Единст- 
венный способ принять нестандартные шаблоны входящих ОВ, состоит в приме- 
нении системы перезаписи ОВГ. но в таком случае не существует простого пути 
генерации исходящих ОЕТ.. (Вполне вероятно, что пользователи МопоКаЙ найдут 
способ применения Зузеет.Иер.БонЕ1т9а и сохранят преимущества.) 


Обе платформы обладают достоинствами и недостатками, но АЗРМЕТ МУС име- 
ет одно огромное преимущество, которое гарантирует его широкое признание: марку 
Мсгозой. Нравится это или нет но наличие марки М1сгозой на самом деле имеет зна- 
чение во многих реальных ситуациях, когда вы пытаетесь склонить клиента или босса к 
тому, чтобы принять новую технологию. Когда слон передвигается. вокруг него вьются 
тучи насекомых: тысячи разработчиков, блогеров и независимых поставщиков компо- 
нентов (да, и авторов!) стремятся занять лучитие места в новом мире АЗРМЕТ МУС. Это 
еще более облегчает поддержку и применение инструментов, а также расптиряет круг 
квалифицированных специалистов. Как ни печально, но все это вряд ли когда-нибудь 
достанется МопоКай. 


Резюме 


Благодаря этой главе, вы смогли оценить, с какой невероятной скоростью эволюциони- 
ровала веб-разработка — от “доисторического болота” ССТ до новейших высокопроизво- 
дительных, совместимых с гибкой методологией платформ. Вы ознакомились с сильными 
и слабыми сторонами, а также ограничениями АЗРМЕТ \еБЕогилз — главной платформой 
веб-разработки Мйсгозой. с 2002 г, а также изменениями в растущей индустрии веб-раз- 
работки, которые вынудили Мсгозой. отреагировать выпуском чего-то нового. 
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Было показано, каким образом в новой платформе АЗРМЕТ МУС учитывались кри- 
тические замечания, адресованные АЗР.МЕТ \еБЕогл$. и описаны ее преимущества для 
разработчиков, которые желают понять НТТР и писать высококачественный, сопрово- 
ждаемый код. Также было подчеркнуто, что эта платформа позволяет получать более 
быстрые приложения, работающие на широком диапазоне устройств. 

В следующей главе на примерах кода будут представлены простые механизмы, кото- 
рые порождают все эти преимущества. К прочтению главы 4 вы будете готовы к созда- 
нию реалистичного приложения электронного магазина, построенного на основе четкой 


архитектуры, правильного разделения сущностей, автоматизированного тестирования 
и изящного лаконичного кода разметки. 


ГЛАВА 2 


Первое приложение 
АЗР.МЕТ МУС 


учший способ освоения платформы разработки программного обеспечения со- 
стоит в том, чтобы просто начать ее использовать. В этой главе будет создано 
простое приложение ввода данных с применением АЗРМЕТ МУС. 


На заметку! В этой главе скорость продвижения преднамеренно снижена. Например, будут да- 
ваться пошаговые инструкции по выполнению мелких задач вроде добавления нового файла 
к проекту. Но уже в последующих главах предполагается наличие знаний языка С# и среды 
\Мзиа! Зшаю-. 


Подготовка рабочей станции 


Перед тем как приступать к написанию кода АЗР.МЕТ МУС, на рабочей станции 
должны быть установлены соответствующие инструменты разработки. Разработка 
АЗРМЕТ МУС требует наличия следующих компонентов: 


® операционная система УЛпдо\уз ХР, Ча, Эегуег 2003, Зегуег 2008 или УЙодо\м?з 7; 


® коммерческая среда \1зпа1 ЭЗилА1о 2008 с ЗР1 (любой версии) или бесплатная среда 
У1зпа1 \еЬ РеуюорттепЕ 2008 Ехргезз с 5Р1. Версия \У1зпа] Зёлаю 2005 не поддер- 
живает разработку приложений АЗРМЕТ МУС. 


Если среда \1зпа1 Зло 2008 с 5Р1 или \У1зпа1 \еЬ Оеу@ортен{ 2008 Ехргез$ с 5Р1 
уже установлена, можно загрузить автономную программу установки АЗРМЕТ МУС, об- 
ратившись по адресу мии.азр.пее/тус/. 

Если же нет ни У! па] Эй1А1о 2008, ни \У1зиа! \еЬ ОеуеюртегЕ 2008 Ехргез$, то лег- 
че всего начать с загрузки и запуска М1сгозой \Ъ РаЧНопи ш$аПег, который досту- 
пен бесплатно на сайте иии.азр.пее/меь/. Этот инструмент автоматизирует процесс 
загрузки и установки последней версии любой комбинации \1з0а] Оеуе!орег Ехргез$, 
АЗРМЕТ МУС, $ОЕ 5егуег Ехргезз$, ПЗ и других полезных инструментов разработки. Он 
очень прост в использовании — просто выберите установку и АЗРМЕТ МУС, и У1зпа1 
МеЬ Реувортепе 2008 Ехргез8". 


Если применяется \Ъ РаНоми ШшзфаПег 1.0, сначала понадобится установить \1з0а! 
\еЬ Пеуаюорег 2008 Ехргез$, а уже потом использовать его для установки АЗРМЕТ МУС. 
Установить то и другое в одном сеансе не получится. В версии \еЪ Ра Ноги ПазфаПег 2.0 
упомянутая проблема решена. 
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На заметку! Хотя приложения АЗРМЕТ М\УС можно разрабатывать в бесплатной среде Миа! еб 
Ремеюрег 2008 Ехргезз, большинство профессиональных разработчиков будут вместо нее поль- 
зоваться \Изна! Зи то, поскольку это более совершенный коммерческий продукт. Почти везде в 
этой книге предполагается применение \Изиа! Зо, а редкие случаи использования \Лзиа! Мер 
Пемеюрег 2008 Ехргез$ будут специально отмечаться. 


Получение и сборка исходного кода платформы 


Технического требования об обязательном наличии исходного кода платформы не предусмотре- 
но, однако многие разработчики АЗРМЕТ М\С предпочитают иметь его под рукой. Если хотите, 
можете получить исходный код МУС по адресу мии. соар1ех.сош/азрпее. 


После распаковки 71Р-архива с исходным кодом в какой-нибудь каталог на рабочей станции мож- 
но открыть в Миа! Зи@ю файл решения Мусрех. 1 п. Сборка должна пройти без каких-либо 
ошибок компиляции, а если у вас установлена версия \Изиа! Зтидю 2008 РгоТеззюпа!, не помешает 
дополнительно выбрать пункт меню Тез{=>Вип=> АП Тез ш Зоной (Тест=>Пуск->Все тесты в 
решении) и прогнать более 1500 модульных тестов на самом АЗРМЕТ МУС. 


Создание нового проекта АЗР.МЕТ МУС 


После установки АЗРМЕТ МУС Егатлемогк вы обнаружите. что в \15ца! Зи о 2008 
появился новый тип проекта АЗРМЕТ МУС \еь АррИсаНон (Веб-приложение АЗРМЕТ 
МУС). Чтобы создать новый проект АЗРМЕТ МУС, откройте \15па] Зло и выберите 
пункт меню Ейе=>Мем=Ргоест (Файл=> Создать=>Проект). Убедитесь, что селектор плат- 
формы (справа вверху) показывает .МЕТ Егатемоик 3.5, и выберите в списке Тетр&ез 
(ГПаблоны) вариант АЗР.МЕТ М\УС М@еь Аррёсаноп, как показано на рис. 2.1. 
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Рис. 2.1. Создание нового веб-приложения АЗРМЕТ МУС 


Вообще-то назвать проект можно как угодно, но поскольку это демонстрационное 
приложение должно обрабатывать ответы на приглашения (КУР — гбропдел $’ уоиз 
Рай) на вечеринку, подходящим именем будет РагуТпу1ез. 
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После щелчка на кнопке ОК первым, что вы увидите, будет всплывающее окно с 
предложением создать проект модульных тестов (рис. 2.2). 
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Рис. 2.2. \Мзиа! Зи тю предлагает создать проект модульных тестов 


С целью упрощения писать тесты для этого приложения не планируется (в главе 3 
вы узнаете, что такое модульные тесты, а в главе 4 научитесь их использовать). Поэтому 
выберите переключатель №, Чо по{ сгеае а ипй 1е${ ргоесе (Нет, не создавать проект 
модульных тестов) (для данного примера можно также оставить выбранным переклю- 
чатель \е$, сгеае а ип {е$Е ргдесЕ (Да, создать проект модульных тестов) — разницы не 
будет). Щелкните на кнопке ОК. 

\15 па] Эйлю создаст стандартную структуру проекта. Поскольку автоматически 
добавляется контроллер и представление по умолчанию, можно нажать <ЁР5> (или вы- 
брать пункт меню ОеБидЗеа“ ОеБидойо (Отладка=Запустить отладку)) и немедленно 
увидеть нечто работающее. Поэкспериментируйте с этим (если отобразится окно с пред- 
ложением включить отладку. просто тцелкните в нем на кнопке ОК). В браузере (ццеглей 
Ехрогег) должен получиться экран, показанный на рис. 2.3. 


Уасоте о АЗР.МЕТ МУС! 


Е с, те, Е = Е 


Рис. 2.3. Новоиспеченное стандартное веб-приложение АЗРМЕТ М\УС 
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По завершении не забудьге остановить отладку, закрыв окно Ицегпе! Ехрогег либо 
вернувшись в \15 10а] 56140 и нажав <ЗЭНИ+ЕБ>. 


Удаление ненужных файлов 


К сожалению, в стараниях быть полезной среда \Изпа! Эва010о иногда заходит слиш- 
ком далеко. Она уже создала для вас скелет мини-приложения, включая регистрацию 
пользователя и аутентификацию. Это затрудняет реальное понимание того, что проис- 
ходит, поэтому давайте удалим это все и вернемся к чистому листу. С помощью ЗойаНоп 
Ехрюгег удалите все файлы и папки, отмеченные на рис. 2.4 (щелкая на них правой 
кнопкой мыши и выбирая в контекстном меню пункт Ве@е (Удалить). 
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Рис. 2.4. Очистка стандартного шаблона проекта 
с целью возврата к осмысленной начальной точке 


Последнее, что понадобится привести в порядок — это содержимое Нотесопето11ег.сз. 
Удалите находящийся в нем код и поместите следующий код класса НомеСопето11ех: 


рерЪ1с сфазз Ношебсопеко11ех : Сопего11Тег 
{ 

руЮ11с зЕг1па Тпаех () 

{ 


тесоко "Не о, мотх1а!"; 


Не особенно впечатляет — просто нам надо вернуться к некоторой начальной базе. 


Попробуйте теперь запустить проект (нажав <Е5>). В браузере отобразится сообщение 
`Не|о, мопа!” (рис. 2.5). 
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Рис. 2.5. Начальный вывод приложения 


Основы функционирования 


В архитектуре “модель-представление-контроллер” (поде-мемх-сопёгоЦег — МУС) кон- 
троллеры отвечают за обработку входящих запросов. В АЗР.МЕТ МУС контроллеры — 
это простые классы С#? (обычно унаследованные от Зузбет.Мер.Мус .Сопеко11етх — 
встроенного базового класса контроллера). Каждый общедоступный метод контроллера 
называется методом действия (асНоп те оа), который можно вызывать через неко- 
торый ОРГ. В данный момент имеется класс контроллера по имени НошеСопего11ек и 
метод действия по имени Тпаех. 

Существует также система маршрутизации (гои/п8 зузетл), которая решает, каким 
образом ОЕТ-адреса отображаются на контроллеры и действия. При стандартной кон- 
фигурации маршрутизации можно запраптивать любой из следующих ОВТ, и все они 
будут обрабатываться действием 1паех класса НомеСопехо11ет: 

о / 

® /Нопе 

® /Нопе/Тпаех 


Поэтому, когда браузер запрашивает БЕЕр://вашСайт/ или ВЕр://вашСайт/Номе, он 
получает вывод метода Тпдех класса НомеСоп*го11ег. Пока что этим выводом является 
строка “НеПо, мойа!”. 


Визуализация веб-страниц 


Если вы добрались до этого места. значит, установленная среда работает нормаль- 
но, к тому же вы только что создали минимальный, однако работающий контроллер. 
Следующим шагом будет генерация некоторого НТМГ.-вывода. 


Создание и визуализация представления 


Контроллер НопеСсопего11ет в нынешнем состоянии посылает в браузер простую 
строку текста. Этого достаточно для отладки, но в реальном приложении, скорее всего, 
понадобится генерировать некоторый НТМГ-документ. Это делается с использованием 
шаблона представления (мех 1етр!а), или просто представления (\1е\). 

Чтобы визуализировать представление из метода Тпаех(), сначала перепишите его 
следующим образом: 


р9611с сфазз НомесопЕко11ехг : Сопего ег 
{ 

руЪ11с У1емВези1* Тпаех() 

{ 


хебокп Улем(); 


} 


? На самом деле строить приложения АЗР МЕТ МУС можно с использованием любого языка 
„МЕЛ (вроде \1зиа! Вазс, ПопРу®оп или ПопКиЪу). Но поскольку в центре внимания книги 
находится С#, с этого момента вместо “все языки .МЕЛ” будет указываться “С#”. 
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Возвращая объект типа \1ехВези1*, вы даете каркасу МУС команду визуализиро- 
вать представление. Поскольку объект У1емВези1е генерируется вызовом У1еи() без 
параметров, каркас визуализирует представление по умолчанию заданного действия. 
Однако если вы попытаетесь запустить приложение в таком виде, то получите сообще- 
ние об ошибке, показанное на рис. 2.6. 
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Рис. 2.6. Сообщение об ошибке, которое отображается, 
когда АЗРМЕТ М\УС не может найти шаблон представления 


Это сообщение более полезно, чем среднестатистическое сообщение об ошибке — 
платформа не только сообщает о том, что не может найти подходящего представления 
для визуализации, но также указывает, где она его искала. Это первый кусочек принци- 
па “соглаитения вместо конфигурации”: шаблоны представлений обычно ассоциируются 
с методами действий посредством соглашения об именовании, а не с помощью явного 
конфигурирования. Когда каркас ищет представление по умолчанию для действия под 
названием Траех в контроллере по имени НотеСопего11ет, он проверяет четыре места, 
показанные на рис. 2.6. 

Чтобы добавить представление к действию Тпдех — и избавиться от отпибок, — 
выполните щелчок правой кнопкой мыши на методе действия (либо на имени метода 
-паех(), либо где-нибудь внутри его тела) и затем выберите в контекстном меню пункт 
АДЯ Мем, (Добавить представление). Это приведет к появлению всплывающего окна, по- 
казанного на рис. 2.7. 
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Рис. 2.7. Добавление шаблона представления для действия Тпдех 
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Снимите отметку с флажка З@ес{ та$ег раде (Выбрать мастер-страницу) (посколь- 
ку в этом примере мастер-страницы не используются) и затем щелкните на кнопке Аа 
(Добавить). Это создаст совершенно новый шаблон представления в корректном месте 
по умолчанию для вашего метода действия: -/У1емз/Номе/Тпаех.азрх. 

После появления окна редактора НТМТ.-разметки \1зпа1 5610103 вы увидите нечто 
знакомое: шаблон НТМГ-страницы, заполненный обычной коллекцией элементов — 
<ВЕп1>, <роду> и тд. Давайте перенесем приветствие Не11о, мог1а! в представление. 
Замените раздел <роау> шаблона НТМИ. следующим: 


<Боау> 
НетТЪо, м"отТЪа (Ехош ®Бе улем) ! 
</Боау> 


Нажмите <Р5>, чтобы снова запустить приложение, и вы увидите шаблон представ- 
ления в действии (рис. 2.8). 


3 Во сса05652543/ - Мчослия Влетией Ехуфогет 


‘2. НИриЧосяйса652943° ых, 


Рис. 2.8. Вывод представления 


Ранее метод действия Тпаех() просто возвращал строку, поэтому каркасу МУС не ос- 
тавалось ничего кроме как послать эту строку в качестве НТТР-ответа. Однако теперь воз- 
вращается объект типа \У1еВези1%, который заставляет каркас МУС визуализировать 
представление. Поскольку имя представления не указывалось. было выбрано имя. при- 
нятое по соглашению для данного метода действия (т.е. ^/У1емз/Ноше/Тпаех.азрх). 

Помимо У1емКези1<, есть и другие типы объектов, которые можно возвращать из 
действия и которые заставляют каркас делать разные вещи. Например, Вед1кесеВези1е 
выполняет перенаправление, а НЕЕрОпаиеВог1теЯВези1* заставляет посетителя заре- 
гистрироваться. Такие вещи называются результатами действий, и все они наследу- 
ются от базового класса Ас&1опКези1. Чуть позже вы узнаете болыне о каждом из них. 
Эти результаты действий позволяют инкапсулировать и повторно использовать общие 
типы ответов, значительно упрощая модульное тестирование. 


Добавление динамического вывода 


Основным смыслом платформы разработки веб-приложений является способность 
конструировать и отображать динамический вывод. В контексте АЗРМЕТ МУС работа 
контроллера заключается в конструировании некоторых данных, а работа представле- 
ния — в их визуализации в виде НТМГ. Это разделение понятий сохраняет аккурат- 
ность приложения. Данные передаются от контроллера представлению с использова- 
нием структуры данных под названием \1емрафа. 

В качестве простого примера измените метод действия Тпаех() в НомеСопегко11ек, 
чтобы он добавлял строку к У1емБафа: 


3 Если вместо этого отобразится \МУЗГАЛС-дизайнер \1зпа1 ЭаАю. переключитесь на пред- 


ставление Зоугсе (Исходный код), щелкнув на вкладке Зоигсе внизу экрана или нажав 
<ЭНН-+Р7>. 
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риБ11с У1емВези1е Тпаех() 

{ 
11 ВБоик = РафеТ1ме .Мом.Нопк; 
У1емРафа ["дгее*1п9"] = (Вопх < 12 ? "бооЯ покизпа" : "бооЯ аЕфегпооп"); 
тесигп У1ем(); 


} 


Далее обновите шаблон представления для ее отображения: 


<роау> 
<%= У1емБафа["дсхгее1т4"] %>, мох1а (Ехот Бе узем) ! 
</Боау> 
На заметку! Здесь используется встроенный (тИпе) код (блок <%=...%>). В мире АЗРМЕТ 


\М/еБРогт$ часто такая практика не поощряется, однако в мире АЗРМЕТ МУС она вполне нор- 
мальна. Отбросьте любые предубеждения, которые у вас могут быть — далее в этой книге вы 
найдете исчерпывающее объяснение, почему для шаблонов представлений М\С встроенный 
код работает очень хорошо. 


Не удивительно, что после запуска приложения (по нажатию <Е5>) динамически вы- 
бранное приветствие появится в браузере (рис. 2.9). 
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Рис. 2.9. Динамически генерируемый вывод, 


Стартовое приложение 


В оставшейся части главы вы узнаете немного больше о базовых принципах АЗРМЕТ 
МУС, построив простое приложение ввода данных. Нашей целью будет просто посмот- 
реть на платформу в действии, поэтому мы создадим приложение, не отвлекаясь на 
объяснение работы каждого его фрагмента. 

Не беспокойтесь, если некоторые части покажутся незнакомыми. Ключевые архи- 
тектурные принципы МУС будут описаны в главе 3, а в последующих главах представ- 
лены детальные объяснения и демонстрации практически всех средств АЗРМЕТ МУС. 


История 


Ваша подружка организует новогоднюю вечеринку. Она попросила вас создать веб- 
сайт, который позволит приглашенным персонам ответить на приглашения (прислать 
электронные В5УР). Это приложение. которое мы назовем Ра{уау Нез, должно обладать 
перечисленными ниже характеристиками. 


1. Иметь домашнюю страницу с информацией о вечеринке. 


2. Включать форму ответа КЗУР в которую приглашенные лица смогут вносить свою 
контактную информацию и сообщать, могут ли они принять приглашение. 

3. Проверять отправленные данные формы, отображая страницу с благодарностью 
в случае успеха. 


4. Отправлять по электронной почте детали заполненных ВКЗУР организатору 
вечеринки. 
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Вряд ли на этом приложении можно будет заработать миллион и уйти на покой, 
однако оно представляет собой хороший старт. Первый пункт из приведенного выше 
списка можно реализовать немедленно: просто добавьте некоторый НТМГ-код в пред- 
ставление Тпдех.азрх: 


<роау> 
<}1>М№ем Уеаг'$ Рагфу</1> 
<р> 
%= У1емрафа ["дгее®119"] %>! Ме'ге до1пд Ко Вауе ап ехс1Е1пд рагу. 
(То ао: зетф 1Е ререехг. Ааа расеогез ог зотефь1та.) 
</р> 
</Боау> 


Связывание действий 


Нам понадобится форма для отправки ответа на приглашение — ВЗУРЕоги, поэтому 
нужно поместить ссылку на нее. Обновите Тпюдех.азрх следующим образом: 


<роау> 
<р1>Мем Уеах'з РагЕу</1> 
<р> 
<%= У1емРафа["огееЕ1па"] %>! Ме'ге до1па фо Вахе ап ехс1Е1п9 рагу. 
(То ао: 5е11 1 рерфегк. Ада расеиагез ох зомесв1тч.) 
</р> 
<%= НЕш?.Асетопт лок ("В$УР Мои", "В$УРЕогм") %> 
</роау> 


На заметку! НЕт1.АсЕторЬ1пК — это вспомогательный метод НТМЕ.. В состав каркаса входит 
коллекция полезных вспомогательных методов НТМЕ, которые предоставляют удобные сокра- 
щения для визуализации не только ссылок НТМЕ, но также текстовых полей ввода, флажков, 
списков выбора и т.п., и даже специальных элементов управления. После ввода <*= НЕш1. 
средство !Че!н$епзе в \Мзиа! Зи отобразит список доступных вспомогательных методов 
НТМЬЕ, из которого можно выбрать нужный. Все они объясняются в главе 10, хотя назначение 
большинства вполне очевидно. 


Запустите приложение снова, и вы увидите новую ссылку, как показано на рис. 2.10. 


' №еу Уеаг'$ Рагбу 


Сосо айегасой! УУате воно то Вате ан ехсйио рабу. (То о: чей & Бенег. Аа 
ребхез ог зоглейнае | 


Рис. 2.10. Представление со ссылкой 


Щелчок на ссылке ВЗ\УР Мом (Ответить сейчас) приводит к получению ошибки “404 
МоЕ Роипа@” (страница не найдена). Заглянув в адресную строку браузера, вы прочтете 
там: вЕЕр://сервер/Нопе/ВЗУРЕоги. Дело в том, что метод Нп1.АсЕ1опЬ1оК проин- 
спектировал конфигурацию маршрутизации и обнаружил, что под текущей конфигу- 
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рацией по умолчанию элемент /Номе/В5УРГоги — это ЧЕТ. для действия под названи- 
ем КЗУРРоги на контроллере по имени НопеСопего11егт. В отличие от традиционных 
АЗРМЕТ УеБРоглаз, РНР и многих других платформ веб-разработки, ОВГ. в АЗРМЕТ МУС 
не соответствуют файлам на жестком диске сервера, а вместо этого отображаются 
через конфигурацию маршрутизации на контроллер и метод действия. Каждый метод 
действия автоматически получает свой собственный ЧЕТ; нет необходимости создавать 
для каждого ОВТ, отдельную страницу или класс. 

Конечно, причина ошибки “404 Моё Еоипа” состоит в том, что метод действия по 
имени В5УРЕОГи() пока не определен. Добавьте в класс НомеСопего11ег новый метод: 


рур11с У1емВезо1е ВЗУРРоги () 
{ 


тееатп Улем(); 


} 


И снова необходимо добавить новое представление, поэтому щелкните правой 
кнопкой мыши внутри этого метода и выберите в контекстном меню пункт АЯа \Ле\м. 
Снимите отметку с флажка Зеес{ тазег раде и щелкните на кнопке Ада; для этого 
действия будет создано новое представление в месте по умолчанию — -/\У1емз/Номе/ 
ВЗУРЕоги.азрх. Пока можно оставить его в том виде, как есть, но имейте в виду, что 
если сейчас вы запустите приложение и щелкнете на ссылке НЗ\УР Мом, в браузере поя- 
вится пустая страница. 


Совет. Существует способ быстрого переключения от метода действия к его представлению по 
умолчанию и обратно. Вот что для зтого нужно. В редакторе \зиа! ЗиЧю установите каретку 
внутри любого из методов действий, выполните щелчок правой кнопкой мыши и выберите в 
контекстном меню пункт Со То \ем/ (Перейти к представлению); можно также нажать ком- 
бинацию <СШ-+М> и затем <СШ+С>. Произойдет немедленный переход непосредственно к 
представлению действия по умолчанию. Чтобы перейти от представления к ассоциированному 
с ним действию, выполните щелчок правой кнопкой мыши в любом месте разметки представ- 
ления и выберите в контекстном меню пункт Со То Сощтго!ег (Перейти к контроллеру) или 
снова нажмите <СИ+М> и затем <С1И-+С>. Этот способ избавляет от блуждания по множе- 
ству открытых вкладок. 


Проектирование модели данных 


Вы можете двинуться дальше и заполнить В5$\УРЕоги.азрх элементами управления 
НТМЕ-форм, но прежде чем делать это, давайте остановимся и подумаем о разрабаты- 
ваемом приложении. 

В аббревиатуре МУС буква М означает модель, которая является самым важным 
персонажем в истории. Модель — это программное представление объектов реального 
мира, процессов и правил, которые составляют суть, или предметную область прило- 
жения. Это центральное хранилище данных и логики (те. бизнес-процессов и правил). 
Все остальное (контроллеры и представления) — это просто механизмы, необходимые 
для представления операций и данных модели в Веб. Хорошо продуманное приложение 
МУС — это не просто случайная коллекция контроллеров и представлений; в нем всегда 
присутствует модель — узнаваемый программный компонент со своими собственными 
правилами. В следующей главе архитектура МУС рассматривается более подробно, а 
также сравнивается с другими похожими архитектурами. 

В приложении РагЕуТрпу1фез нет особой необходимости в модели предметной об- 
ласти, но здесь есть один очевидный тип модели, который мы назовем СоезЕВезропзе. 
Этот объект будет отвечать за сохранение, проверку и в конечном итоге подтверждение 
В5УР приглашенного лица. 
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Добавление класса модели 


Воспользуйтесь ЗолНоп Ехрюогег для добавления нового пустого класса С# по имени 
сиезЕВезропзе в папку /Моде1з, после чего добавьте к нему некоторые свойства: 


2уЬ11с с1азз Соез&Везропзе 

{ 
рчю11с зх1по Маме { её; зеё; } 
рур11с $зЕ:1ид Ема11 { еб; зес; } 
руЮ11с $з&:1ид Рропе { ее; зе®; } 
р9ю11с 6001? И11Т1АЕЕепра { деё; зеф; } 

} 


В этом классе используются автоматические свойства С# 3.0 (те. { де; зеё; }). 
Не беспокойтесь, если вы еще не знакомы с версией С# 3.0 — новый синтаксис будет 
кратко описан в конце следующей главы. Также обратите внимание, что 111 Абкепа 
имеет тип ©оо1, допускающий значения поа11 (на зто указывает вопросительный знак). 
Это позволит создавать величины, принимающие три значения — Тгие, Ра1зе и пи11, 
причем последнее означает, что гость пока не указал, принимает ли он приглашение. 


Построение формы 


Теперь наступил момент поработать с представлением В5\УРЕогиз.азрх, превратив 
его в форму для редактирования зкземпляров СиезеВезропзе. 

Вернитесь к В5УРЕогиз.азрх и воспользуйтесь встроенными вспомогательными ме- 
тодами АЗРМЕТ МУС для конструирования НТМГ-формы: 


<Боду> 
<61>8В5УР</в1> 
<% и51по (НЕ .ВедапРоги()) { %> 
<р>Уоцг паше: <%= Нёт1 .ТехЕВох{"Маше") %></р> 
<р>Уопг ета11: <%= Не .ТехЕВох ("Ема11") %$></р> 
<р>Уоиг рбопе: <%= Нёи1.техеВох ("Рвопе") $></р> 
<р> 
111 уой абфепа? 
<%= НЫ .БгоррБомот1 3% ("И111АбеепрЯ", пем[] { 
лем зетесета5ЕТеем { ТехЕ = "уез, Г'11 ре &веге", 
Уа1е = 6оо1.Ткиебет1па }, 
пем Зе1есеТ1зеТеем { Техе = "Мо, Т сап'® соме", 
Уа1ие = роо1.Ра1зебет1иа } 
}, "СБоозе ап орЕ1ойр") %> 
</р> 
<1прое суре="зириае" уа]1зе="бори1е В$МР" /> 
<% } %> 
</Боау> 


Для каждого злемента формы задается параметр папе, указывающий имя связанно- 
го НТМЕ-дескриптора (например, Ета11). Эти имена в точности соответствуют именам 
свойств Сиез&Кезропзе. так как по существующему соглашению АЗРМЕТ МУС ассоции- 
рует каждый элемент формы с соответствующим свойством модели. 

Обратите внимание на вспомогательный синтаксис <% аз1пд(Нем1.Вес1иЕоги(...)) 
{ ... } 3>. Это изобретательное применение синтаксиса С# п31п9 визуализирует от- 
крывающий НТМГ-дескриптор <Еоги> при первом появлении и закрывающий дескрип- 
тор </Еогт> в конце блока 131109. В НЕм1.Вед1пРоги() можно передавать параметры, 
сообщающие, какой метод действия должен получить данные формы при ее отправке. 
В примере параметры не передаются, поэтому данные формы передаются по тому же 
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самому ОВГ, по которому она была вызвана. В результате этот вспомогательный метод 
продуцирует следующую НТМГ-разметку: 
<Еотги асЕ1оп=" /Номе/В5УРЕогм" меброд=“розе" > 


... Содержимое формы ... 
</Еоги> 


На заметку! “Традиционная” платформа АЗРМЕТ МебРогтз требует помещения всей страницы 
строго в одну форму серверной стороны (<Еогм гипае="зекуетг">), которая представляет 
собой контейнер \МебРопт$ для данных Мем а и логики обратной отправки. Но платфор- 
ма АЗР.МЕТ МУС формы серверной стороны не использует. Она работает с простыми НТМ(- 
формами, которые определяются дескрипторами <Еогит>, обычно, но не обязательно генери- 
руемыми вызовом НЕм1.Вед1пРогм().В одном представлении можно иметь произвольное 
количество таких форм. НТМ!-разметка этих форм совершенно чиста — отсутствуют какие- 
либо скрытые поля (вроде _ УТЕМЗТАТЕ), дополнительные блоки Чауа$сир!-кода, а также ис- 
кажение идентификаторов злементов. 


Давайте посмотрим, как выглядит новая форма. Перезапустите приложение и щелкни- 
те на ссылке АЗУР Мом. На рис. 2.11 можно видеть построенную форму во всей ее красе“. 
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Рис. 2.11. Вывод представления ВЗУРГогп.азрх 


Куда подевались введенные данные? 


Если вы заполните форму и щелкнете на кнопке Зиртй ВЗ\УР (Отправить ответ), про- 
изойдут странные вещи. Та же форма немедленно появится снова, но все поля ввода бу- 
дут пустыми. Что произошло? Поскольку зта форма отправляется на /Номе/ВЗУРГоги, 
метод действия В5УРЕогт() запускается заново и визуализирует то же самое представле- 
ние. Поля ввода оказываются пустыми, потому что все введенные ранее значения отбра- 
сываются, так как вы ничего не сделали для того, чтобы принять или обработать их. 


* Поскольку зта книга посвящена отнюдь не стилям С$$ или веб-дизайну, в болыпинстве 
примеров мы будем придерживаться “образца 1996 года". Благодаря тому, что АЗРМЕТ МУС 
генерирует простую чистую НТМ!-разметку. предоставляя полный контроль над идентифи- 
каторами и компоновкой элементов, вы можете без проблем воспользоваться любым гото- 
вым шаблоном веб-дизайна или библиотекой эффектов Зауа$спре. 
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На заметку! Формы в АЗРМЕТ М\С ведут себя не так, как формы в АЗРМЕТ \МебРогтз! В АЗРМЕТ 


МУС намеренно не предусмотрена концепция “обратной отправки” (розФаск), позтому при 
многократной визуализации одной и той же формы подряд нельзя рассчитывать на то, что 
поле ввода сохранит свое содержимое. Текстовое поле в новом запросе даже не должно трак- 
товаться, как то же самое поле, что было в предыдущем запросе: поскольку протокол НТТР 
не поддерживает состояние, элементы управления вводом, визуализируемые при каждом за- 
просе, полностью перерождаются и совершенно независимы от своих предшественников. Тем 
не менее, добиться эффекта сохранения значений в элементах ввода несложно, и зто будет 
описано ниже. 


Обработка отправки формы 


Чтобы получить и обработать отправленные данные формы, мы сделаем одну умную 


вещь. Разделим действие ВЗУРЕоги “пополам”, создав два следующих метода. 


®_ Один метод, реагирующий на НТТР-запросы СЕТ. Обратите внимание, что запрос 
СЕТ — это то, что браузер обычно издает, когда пользователь щелкает на ссылке. 
Эта версия действия будет отвечать за отображение начальной пустой формы, 
когда кто-либо впервые посещает /Нопе/В5\УРЕогм. 


® Другой метод, отвечающий на НТТР-запросы РОБТ. По умолчанию формы, ви- 
зуализируемые с помощью НЕп1.Вед1пЕогм(), отправляются браузером в виде 
запроса РОЗТ. Эта версия действия будет отвечать за получение отправленных 
данных и принятие решения, что с ними делать дальше. 


Написание этих двух отдельных методов С# поможет сохранить код аккуратным, по- 


скольку они имеют совершенно разную ответственность. Однако извне зта пара мето- 
дов С# будет выглядеть как единое логическое действие, поскольку они получат одно и 
то же имя и будут вызываться через один и тот же ОВГ. 


Замените текущий единственный метод В5УРЕогм() следующим кодом: 


[АссеръУетЬз$ (НебрУетЬ$ .Сеф) ] 
ру611с У1еВеза1е В$УРЕРоги () 
{ 

тееаги Утем(); 


} 


[Ассере\Уегьз (НЕрУеть$ .Роз®) ] 

рую11с У1течВези1е ВЗУРГоги (СиезсКезропзе даезеВезропзе) 

{ 
// Тоао: Отправить по электронной почте дипезЕВезропзе организатору вечеринки 
тебаги Узем ("ТВарпк$з", диез®Везропзе); 


Совет. Чтобы среда \Изиа! Зи смогла распознать Соез(Везропзе, потребуется импортировать 


пространство имен Рае уТп\у1ее$ .Моде1з. Самый простой способ — установить каретку в 
позицию не распознанного слова СиезЕВезропзе и нажать комбинацию <С1+.>. В появив- 
шемся окне с запросом следует нажать <Етег>. Нужное пространство имен импортируется 
автоматически. 


Назначение атрибута [АссерЕ\егЬз] понять несложно. Когда он присутствует, он ог- 


раничивает тип НТТР-запроса, на который будет отвечать действие. Первая перегрузка. 
ВЗУРЕогим() будет отвечать только на запросы СЕТ; вторая — только на запросы РОЗТ. 
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Привязка модели 


Первая перегрузка просто визуализирует то же представление по умолчанию, что и 
ранее. Вторая перегрузка более интересна, поскольку принимает в качестве параметра. 
экземпляр СиезЕВезропзе. Учитывая. что метод вызывается через НТТР-запрос, и что 
СиезЕВезропзе является типом .МЕТ, который совершенно неизвестен протоколу НТТЕР, 
возникает вопрос: как применить экземпляр СиезЕВезропзе к запросу НТТР? Ответом 
будет привязка модели (тоае! Ып@и15) — исключительно полезное средство АЗРМЕТ 
МУС. С его помощью осуществляется автоматический разбор входных данных, после 
чего, посредством сопоставления входящих пар “ключ/значение” с именами свойств 
заданного типа .МЕТ, резульгатами этого разбора заполняются параметры метода 
действия. 

Этот мощный и настраиваемый механизм исключает болыпую часть запутанной 
логики, ассоциируемой с обработкой НТТР-запросов, позволяя работать в терминах 
строго типизированных объектов .МЕТ вместо низкоуровневых манипуляций со сло- 
варями Ведиезе.Еоги[] и Кедиезе .Опегу5Ет1п9[], как это часто приходится делать 
в \еБРогол$. Поскольку элементы управления вводом, определенные в К5УРЕоги.азрх, 
имеют имена, соответствующие именам свойств в Соез(Везропзе, каркас передает 
методу действия экземпляр Соез Везропзе, заполненный данными, которые пользова- 
тель ввел в форму. Весьма удобно! 


Строго типизированные представления 


Вторая перегрузка ВЗУРЕогт() также демонстрирует, как визуализировать специфи- 
ческий шаблон представления, который не обязательно совпадает с именем действия, 
и как передать одиночный специфический объект модели, которую необходимо визуа- 
лизировать. Вот строка. о которой идет речь: 


тесаги У\У1ем ("ТБапкз", даезЕВезропзе); 


Эта строка заставляет АЗРМЕТ МУС найти и визуализировать представление по 
имени ТВапкз, а также применить объект доезеВезропзе к этому представлению. 
Поскольку все это происходит в контроллере по имени НомеСоп{го11етг, АЗРМЕТ МУС 
предполагает найти представление ТВапкз в -/У1емз/Номе/ТВапК$.азрх, но, конечно. 
не находит, так как этого файла еще нет Давайте создадим его. 

Создайте новое представление. щелкнув правой кнопкой мыши внутри любого 
метода действия в НопеСопеЕ ко11ек и выбрав в контекстном меню пункт АЯЯ \Ме\м. 
На зтот раз представление будет несколько отличаться: мы укажем, что оно в пер- 
вую очередь предназначено для визуализации одного специфического типа объекта 
модели, а не как предыдущие представления, которые просто визуализировали про- 
извольную коллекцию элементов из структуры У1емрафа. Тем самым мы создадим 
строго типизированное представление. и чуть ниже будет показано. в чем состоят 
его преимущества. 

На рис. 2.12 можно видеть опции, которые должны быть установлены во всплываю- 
ем окне Ада \Лем/ (Добавить представление). Введите имя представления — Тпапк$, 
снимите отметску с флажка Зеес! та$ег раде (Выбрать мастер-страницу} и на этот 
раз отметьте флажок СгеаЕ а знопсу Туред мем/ (Создать строго типизированное пред- 
ставление). В раскрывающемся списке \Мем/ даа с!аз$ (Класс данных представления} 
выберите тип Соез&Везропзе. В поле Ме\м/ сотег{ (Содержимое представления) оставь- 
те значение Етр\у (Пусто). Наконец, щелкните на кнопке Ада (Добавить). 
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Рис. 2.12. Добавление строго типизированного представления 
для работы с определенным классом модели 


И вновь \У150а! За о автоматически создаст новый шаблон представления в мес- 
те, отвечающем соглашениям АЗРМЕТ МУС (на зтот раз им будет -/\М1еиз/Номе/ 
Трапкз.азрх). Это представление строго типизировано для работы с экземпляром 
СиезЕВезропезе, те. визуализируемым экземпляром. Введите следующую разметку: 


<роау> 
<61>ТВапКк уоп, <%= Не] .Епсоде (Моае1 .Маше) %>!</61> 
<% 1Е (Моае1 .И11ТАЕЕепа == 6кое) { $> 
ТЕ'5 дгеаЕ ЕВаф уоп'ге соп1пд. Те ахликз аге а1теаЧу 1п ЕВе Ёг19де! 
<$ ре1зе { %> 
боггу Ко Беаг уоц сап’® маке 1%, Боф ЕВарКкз Рог 1ееЕ1п9 из Кром. 
<$ } $5> 
</Боау> 


Огромное преимущество использования строго типизированных представлений со- 
стоит в том, что вы не только точно знаете, какой тип данных визуализирует представ- 
ление, но также получаете полную поддержку п\еШЗепзе для этого типа (рис. 2.13). 

Теперь можно запустить приложение, заполнить форму, отправить ее и увидеть ос- 
мысленный результат, как показано на рис. 2.14. 
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Рис. 2.13. Строго типизированные представления позволяют использовать и\еЗепее 
для выбранного класса модели 
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Рис. 2.14. Вывод представления ТВапкз.азрх 


Совет. Не забудьте защитить приложение от атак межсайтовыми сценариями, выполнив НТМЕ- 
кодирование любого пользовательского ввода, который будет отправляться обратно. Например, 
ТВарК$.азрх содержит блок кода вида <%= НЕм1 .Епсоде (Моде1 .Маме) %>, а не просто 

%= Моде] .Маше %>. Более подробно о мерах безопасности речь пойдет в главе 13. 


Добавление проверки достоверности 


Вы могли заметить. что до сих пор никакая проверка достоверности не выполнялась. 
Вместо адреса злектронной почты можно вводить любую бессмыслицу, можно даже от- 
правлять совершенно пустую форму. 

Наступило время прояснить зто, но прежде чем приступить к рассмотрению элемен- 
тов управления проверкой достоверности, напомним, что мы имеем дело с приложени- 
ем МУС, а в соответствии с принципом “не повторяться”, проверка достоверности — это 
функция модели, а не пользовательского интерфейса. Проверка достоверности часто 
отражает бизнес-правила, которые лучше всего поддерживать, когда они выражены в 
одном и только одном месте, а не разбросаны по множеству классов контроллеров и 
файлов .азрх и .азсх. Возлагая обязанность контроля достоверности на модель, вы 
также гарантируете, что целостность ее данных будет всегда защищена одинаково, не- 
зависимо от того, какой к ней подключается контроллер или представление. Это ре- 
шение более устойчиво, чем применение элементов управления <азр:Ху7\Уа11Яафог> 
пользовательского интерфейса в стиле \’еЬКогилз. 

Существует множество способов реализации проверки достоверности в АЗРМЕТ 
МУС. Прием, который демонстрируется ниже, является простейшим. Разумеется, он не 
столь аккуратный или мощный, как некоторые альтернативы, рассматриваемые далее 
в книге. Отредактируйте класс СиезЕВезропзе, добавив в него реализацию интерфейса 
ТРафаЕхкогТи о. Исчерпывающее объяснение ТРабаЕггогТпРо отложим на потом; пока 
достаточно того, что этот интерфейс просто предоставляет средства для возврата сооб- 
щений о возможных ошибках проверки достоверности для каждого свойства. 


р9ю11с с1азз Саез Везропзе : ТРабаЕгкохТиаЕо 
{ 
рч611с зЕг1па Маше { деф; зеб; } 
руЮ11с зЕк1па Етма11 { дее; зес; } 
руЮ11с зег1па Рропе { дес; зеф; } 
руБ11с 6001? И11ПАЕЕепа { деё; зеф; } 
РУБ11Ас зЕг4па Екког { де { кебагсп по11; } } // В данном примере не требуется 
РиБ11с зфг1па 61$ [зЕг1пд ргорМате] 
{ 
дет { 
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1Е( (реорМаше == "Маше") && зе к4пад.ТзМ№а11ОкЕпреу (Мате) ) 
хебакп "Р1еазе епфег уойпхг пате"; // не было введено имя 
1Е ((ргорМаше == "Епа11") && 'Ведех.ТзМафсьЬ (Ета11, ".+\\6.+\\..+")) 


гебакп "Р1еазе епфег а уа114 ета11 аЯагезз"; 
// был введен неправильный адрес ета41 
1Е ((ргорМаше == "Рропе") && зёг1па. ТзМ№а11ОгЕпреу (РВопе)) 
гебакп "Р1еазе епфег уоцк рЬопе попбег"; 
// не был введен телефонный номер 
1Е ((ргорМаше == "И111Аефепа") && 'М11ТАЕфепа. НазУа1ме) 
хебакп "Р1еазе зрес1Еу мвефрег уоц’11 аеепа"; 
// не было указано, планируется ли посещение 
теёцкп поа11; 


На заметку! Нужно будет добавить операторы и31п9 для Зузфем.СотропепЕМоде1 и бузбет. 
Техе.Кеди1атЕхргезз1оп. Миа! Зию может сделать это автоматически, если вы нажме- 
те комбинацию <С+.>. 


Если вы — сторонник злегантного кода, можете воспользоваться каким-нибудь кар- 
касом проверки достоверности, который позволит свести все это к нескольким атрибу- 
там С#, прикрепленным к свойствам объекта модели (например, [\а11За+кеЕща111)5. 
Однако для такого небольшого приложения вполне подойдет и описанная выше техни- 
ка — ввиду своей простоты и читабельности. 

АЗР.МЕТ МУС автоматически распознает интерфейс ТРафаЕггогТпЕо и использует 
его для проверки достоверности входящих данных, когда выполняет привязку модели. 
Давайте обновим второй метод действия ВЗУРЕГоги(), чтобы в случае обнаружения оши- 
бок при проверке достоверности он повторно отображал представление по умолчанию 
вместо визуализации представления ТВапК$: 


[АссереУетьз (НЕрУетЬ$ .РозЕ) ] 
ру611с У1еВеза1Е ВЗУРЕРогм (СоезЕБКезропзе дез Везропзе) 
{ 
1Е (Моде15фафе.ТзУа11а) { 
// Тодо: Отправить по электронной почте длезКезропзе организатору вечеринки 
гебакп У1ем ("ТВапКкз", даезЕВезропзе); 
} 
е1зе // Ошибка проверки достоверности, поэтому отобразить форму ввода данных заново 
гебагп У1ем(); 
} 


И, наконец, выберите, где отображать сообтцения об оптибках проверки достоверно- 
сти, добавив Нем1 \№а11Ча&1опбиимаку() к представлению В5УРЕогм.азрх: 


<Боау> 
<61>В5\УР</Ъ1> 
<%= Нет1 .Уа11Ча&1опбиитаку() %> 
<$ п5$1п9 (НЕп1.ВедлипРогм()) { %> 


. остальной код оставить без изменений ... 


Если теперь попробовать отправить пустую форму или ввести неверные данные, 
появится соответствующее сообщение (рис. 2.15). 


5 Такой каркас проверки достоверности позволяет избежать жесткого кодирования сообщений 
об оптибках, а также облегчает интернационализацию. Подробнее об этом читайте в главе 11. 
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Рис. 2.15. Средство проверки достоверности в действии 


Повторное отображение элементами управления 
введенных значений с помощью привязки модели 


Ранее уже упоминалось, что так как протокол НТТР не поддерживает состояния, 
не следует ожидать, что элементы управления вводом будут сохранять свое состояние 
между множеством запросов. Однако поскольку теперь для разбора входящих данных 
используется привязка модели, обнаруживается, что при отображении ошибок провер- 
ки достоверности злементы управления сохранят и заново отобразят все введенные 
пользователем значения. Создается впечатление хранения состояния элементов управ- 
ления — как раз то, что пользователь ожидает. Этот удобный легковесный механизм 
встроен в системы привязки моделей АЗРМЕТ МУС и вспомогательных методов НТМГ.. 
Он подробно рассматривается в главе 11. 


На заметку! Если вы работали с платформой АЗР.МЕТ МебРогтз, то знаете, что в ней имеется 
концепция “серверных злементов управления”, которые сохраняют состояние, выполняя се- 
риализацию значений в скрытое поле по имени _ УТЕИЗТАТЕ. Будьте уверены, что привязка 
модели АЗР.МЕТ МУС не имеет совершенно ничего общего с концепцией серверных злементов 
управления, обратными отправками или Лема. Механизм АЗРМЕТ М\УС не добавляет в сге- 
нерированные НТМЕ-страницы ни скрытого поля __ УТЕИЗТАТЕ, ни чего-либо подобного. 


Завершающие штрихи 


Последнее требование связано с отправкой заполненных форм В$УР организатору 
вечеринки. Это можно сделать непосредственно в методе действия, однако более ло- 
гично включить это поведение в модель. В конце концов, могут существовать и другие 
пользовательские интерфейсы, работающие с той же моделью и желающие присылать 
объекты СиезЕВезропзе. 
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Добавьте в класс СоезЕБезропзе следующие методы е: 


р9611с уо1а Забил () 


{ 
ЕрпзогеСоггеп®1у\а114(); 


// Отправить по электронной почте 

уаг шеззаде = пем 5Ег1пдВоз1аех (); 

пеззаде.АррепЯРотгма* ("Рафе: {0:уууу-ММ-аа ВВ:пит}\п", Бабетлие.Мом); 
пеззаде .АррепЯРогптаф ("В5УР Егош: {0}\п", Маме); 

пеззаде.АррепаЕогма® ("Ема11: {0}\п", Ема11); 

пеззаде .АррепдГогиа® ("Рвопе: {0}\п", Рвопе); 

пеззаде.АррепаРогта* ("Сап соме: {0}\п", И111ТАесера.Уа1 че ? "Уез" : "Мо"); 


ЗпЕрС11епе зпёрС11ей® = пем ЗшЕрс11ере(); 
эмЕрСс11епе.бепа (пем Ма11Меззаде ( 


"гзурз@ехатр1е. сом", // От 

"рагхеу-огдап1тег@ехапр1е. сом", // Кому 

Маше + (М111Асфепа.Уа1ще ? " м111 афера" : " иоп'Е афера"), // Тема 
пеззаде. То5Ег1пд () // Тело сообщения 


)); 
} 


рг1хафе уо1а ЕпзигеСигкепй Е 1уУ\Уа11а () 
{ 
// является достоверным, если ТРабаЕггогТпЕо.&№1$[] возвращает пи11 
// для каждого свойства 
уаг ргорзТоУа11Чафе = пем[] { "Маше", "Ета11", “РЬопе", "И111Абстера" )}; 
Боо1 13\Уа11а = ргорзТоУ\а11Ааее.А11 (х => &11$[х] == 0011); 
ЗЕ (1!1з\/а11а) 
// Недопустимый СоезЕВезропзе отправлять нельзя 
Ерком пем Тпуа1190рега 1опЕхсере1оп ("Сап'& зи 1пуа11а СоезЕВезропзе"); 


} 


Если вы незнакомы с понятием лямбда-методов С# (те. х => &61$[х]| == по11), 
обратитесь к последним разделам главы 3, где они объясняются. 

И, наконец, вызовите 5ири1е() из второй перегрузки ВЗУРЕоги(), отправляя прове- 
ренный ответ гостя по электронной почте: 


[АссереУетЬз (НЕЕрУетЬ$ .Роз®) ] 
ру611с \У1ечВези1е В5\УРРоги (СиезеВезропзе даез®Везропзе) 
{ 
1Е (Моде15еаъе.тТз\Уа11а) 
{ 
дчез*Везропзе . биЪ м1 (); 
тееиаги У1ем ("ТВарКкз", доез&Везропзе); 
} 
е1зе // Ошибка проверки достоверности, поэтому заново отобразить форму ввода данных 
хебаки Узем(); 


} 


Как и было обещано, класс модели СиезЕВезропзе защищает собственную целост- 
ность, не позволяя выполнять отправку недостоверных данных. Уровень модели не мо- 
жет просто полагаться на то, что уровень пользовательского интерфейса (контроллеры 
и действия) будет всегда знать и соблюдать его правила. 


5 Потребуется также добавить операторы и34п4 Зузееш; 5119 Зузкем.Мее.Ма11; и 
1181па бузтей.Техе;. 
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Конечно, чаще принято хранить данные модели в базе данных, чем отправлять их 
по электронной почте, и в этом случае объекты модепи обычно проверяют себя перед 
помещением в базу. В главном примере главы 4 будет демонстрироваться один из воз- 
можных способов использования АЗРМЕТ МУС с ЗОТ, Зегуег 


м 
Конфигурирование ЗпЕрс11епе 


В зтом примере для отправки электронной почты используется АР!-интерфейс „МЕТ ЗпЕрСс1тепе. 
По умолчанию он берет настройки почтового сервера из файла эеЪ.сопЕ19. Чтобы сконфигури- 
ровать его для отправки электронной почты через определенный ЗМТР-сервер, добавьте в файл 
мер .сопЕ1а следующий фрагмент: 


<сопЕ1дахае1оп> 
<зузеем.пее> 
<па115е119$> 
<зтЕр ае11уехуМефкояа="Мефиотгк"> 
<пебмогК Нозф="зиёр.ехатр1е.сом"/> 
</зтЕр> 
</та11Зе1па3> 
</зузфет.пеф> 
</сопЕ1датхаЕ1оп> 


Во время разработки имеет смысл сохранять сообщения в локальном каталоге, не используя 
действующий почтовый сервер. Ниже приведены соответствующие настройки: 


<сопЕ1 дика 1оп> 
<зузвем.пе®> 
<па115е1па$> 
<зтЕр Ч9е15уегуМеВод=" Зрес1Е1еЯР1скарр1гесвогу"> 
<5рес1Е1еЯР1скарр1хес®огу р1скаро1гесвокуГгоса1оп="с: \еша11" /> 
</этЕр> 
</та11$е1195> 
</зузеет.пее> 
</сопЕ1дагаЕ1оп> 


Это позволит записывать файлы „.етм1 в специфический каталог (здесь — с:\ета11), который 
должен существовать и быть доступным для записи. Двойной щелчок на файлах .етЕ в ММпдом$ 
Ехрюгег вызывает открытие приложения ОиНоок Ехргез$ или Мйпдомз Май. 


Резюме 


В этой главе было показано, как построить простое приложение ввода данных с ис- 
пользованием АЗРМЕТ МУС — вы смогли получить первоначальное представление о 
работе архитектуры МУС. Приведенный пример не демонстрирует всю мощь МУС (на- 
пример, пока речи не шло о маршрутизации и автоматизации тестирования). В сле- 
дующтих двух главах подробно рассматриваются аспекты разработки, позволяющие соз- 
давать качественные и современные веб-приложения МУС, и будет предложен пример 
построения полноценного сайта электронного магазина, более полно демонстрирующий 
возможности этой платформы. 


ГЛАВА 3 


Предварительные 
условия 


режде чем приступить в следующей главе к созданию реального приложения 
АЗРМЕТ МУС электронного магазина, важно ознакомиться с применяемой архи- 


тектурой, шаблонами проектирования. инструментами и приемами. В этой главе рас- 
сматриваются следующие вопросы. 


Архитектура МУС. 
Модели предметной области и служебные классы. 


Создание слабо связанных систем с использованием контейнера инверсии управ- 
ления (Гпуегзоп оЁ Соп®то| — ТоС). 


Основы автоматизированного тестирования. 


Новые языковые средства версии С# 3.0. 


Возможно, с этими вопросами вы никогда ранее не сталкивались, а может быть, 
использовали только некоторую их комбинацию. Если что-то покажется знакомым — 
пропускайте и двигайтесь далее. Болышинство читателей найдет здесь массу нового 
материала, и пусть это всего линь краткий обзор, он закладывает фундамент для эф- 
фективного применения МУС. 


Определение архитектуры 
“модель-представление-контроллер” 


К этому моменту вам должно быть известно. что приложения АЗРМЕТ МУС строят- 
ся на основе архитектуры “модель-представление-контроллер” (тоде-ех-сопёгоПег — 
МУС). Но что она собой представляет и каково ее назначение? В самом общем виде при- 
ложение разделяется на (минимум) три отдельные части. 


Модель, которая представляет элементы, операции и правила, имеющие опреде- 
ленный смысл в предметной области приложения. В банковском деле к элементам 
можно отнести банковские счета, кредитные лимиты, к операциям — переводы 
средств, а правила могут требовать, чтобы баланс на счетах оставался в пределах 
кредитных лимитов. Модель также хранит состояние мира приложения на теку- 
щий момент, но она полностью избавлена от какого-либо упоминания пользова- 
тельского интерфейса. 
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® Набор представлений, описывающих визуализацию некоторой части модели в 
виде наглядного пользовательского интерфейса, но не содержащих в себе ника- 
кой логики. 


® Набор контроллеров, которые обрабатывают входящие запросы, выполняют опе- 
рации над моделью и выбирают представление для визуализации пользователю. 


Существует множество вариаций паблона МУС, каждый имеет собственную терми- 
нологию и неболышие отличия в акцентах, но все они преследуют одну общую цель — 
разделение ответственности. При строгом разделении ответственности приложение 
проще сопровождать и развивать на протяжении его жизненного цикла, независимо 
от того, насколько болышим оно станет. В последующем обсуждении не будут исполь- 
зоваться точные академические или исторические определения каждого аспекта МУС; 
вместо этого вы узнаете, почему МУС является настолько важной архитектурой, и как 
она эффективно работает в рамках АЗРМЕТ МУС. 

В некоторых отношениях проще всего понять шаблон проектирования МУС, поняв 
чем он не является, поэтому давайте начнем с рассмотрения альтернатив. 


Антишаблон Этан Ц 


Чтобы построить приложение с интеллектуальным интерфейсом (Этаг 01), разра- 
ботчик сначала конструирует пользовательский интерфейс — перетаскивает набор гра- 
фических элементов на полотно! и наполняет кодом обработчики событий для каждого 
возможного щелчка на кнопке или другого события. Вся логика приложения располо- 
жена в обработчиках событий: логика для приема и проверки пользовательского ввода, 
- для выполнения доступа к данным и их хранения, а также для предоставления отклика 
обновлением пользовательского интерфейса. Все приложение состоит из этих обработ- 
чиков событий. По существу это то, что получается у новичка, когда он начинает при- 
менять \ 15а] ЭваА1о. 

При таком дизайне разделение ответственности вообще отсутствует. Все смешано 
в кучу; разделение производится только в терминах различных событий пользователь- 
ского интерфейса, которые могут произойти. Если логика или бизнес-правила должны 
применяться в более чем одном обработчике, код обычно просто копируется из одного 
обработчика в другой, или же некоторые произвольно выбранные сегменты выносятся 
в статические служебные классы. По многим очевидным причинам такого рода шаблон 
проектирования часто называют антишаблоном (ап/-ра{егп). 

Давайте не станем слишком задерживаться на Этай ОТ. Все мы разрабатывали по- 
добные приложения, и фактически такой дизайн даже обладает рядом преимуществ, 
которые делают ето наилучшим выбором в определенных ситуациях. 


1. Он позволяет получить видимый результат исключительно быстро. За какие-то 
дни или даже часы можно получить нечто функциональное и продемонстриро- 
вать это клиенту или боссу. 


2. Если проект очень мал (и не будет расти), те. сложность никотда не станет пробле- 
мой, то стоимость более изошренной архитектуры перевешивает ее преимущества. 


3. Имеется наиболее очевидная ассоциация между элементами графического поль- 
зовательского интерфейса и подпрограммами в коде. Это приводит к очень про- 
стой ментальной модели для разработчиков, которая может оказаться единствен- 
но возможным выбором для команды разработчиков с невысокой квалификацией 
и опытом. В этом случае попытки построить более сложную архитектуру могут 


+ В АЗРМЕТ \еЪЕоггаз для этого пишется набор дескрипторов, оснащенных специальным ат- 
рибутом гопа*="зегуег". 
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просто привести к потраченному впустую времени и худшему результату, чем с 
использованием Эта“ ОТ. 


4. Метод копирования-вставки несет в себе естественный (хотя и извращенный) вид 
уменьшения степени связанности системы. Во время сопровождения можно из- 
менить индивидуальное поведение или исправить отдельную оптибку, не опаса- 
ясь, что это затронет другие части приложения. 


Вы, вероятно, имели возмозкность столкнуться с недостатками такого антишаблона 
проектирования. Сопровождение таких приложений усложняется экспоненциально с 
добавлением каждого нового средства: поскольку определенной структуры не сущест- 
вует, запомнить, что делает та или иная часть кода, не удастся. Во избежание рассогла- 
сованности, изменения приходится проводить в нескольких местах; и, очевидно, нет 
никакой возможности создавать модульные тесты. В пределах одного или двух челове- 
ко-лет такие приложения имеют тенденцию руптиться под собственным весом. 

Вполне допустимо принимать обоснованное решение о построении приложения в 
стиле Этан ЧТ, когда вы чувствуете, что это обеспечит достижение наилучшего ком- 
промисса между “за” и “против” (в этом случае используйте классическую технологию 
У’еЬЕогтлз, а не АЗРМЕТ МУС, потому что УеБЕогилз поддерживает более простую модель 
событий} и конечный потребитель согласен с ограниченным временем жизни получен- 
ного в результате приложения. 


Выделение модели предметной области 


В ответ на ограничения архитектуры Этаг О] появилось птироко признанное усо- 
вершенствование, которое сулит огромные выгоды в части стабильности и сопровож- 
даемости приложений. 

Идентифицируя сущности реального мира. операции и правила. действующие в от- 
расли или субъекте, на который вы нацелены (предметной области}, и создавая про- 
граммное представление этой предметной области (обычно объектно-ориентированное 
представление, поддерживаемое системой постоянного хранения наподобие реляцион- 
ной базы данных), вы создаете модель предметной области. Какие выгоды это дает? 


® Во-первых, это естественное место для размещения бизнес-правил и прочей логики 
предметной области. В резульгате одни и те же бизнес-процессы происходят вне за- 
висимости от того, какой конкретно код пользовательского интерфейса выполняет 
операции в предметной области (например “открьмъ новый банковский счет”). 


® Во-вторых, это дает очевидную возможность сохранять и восстанавливать состоя- 
ние мира приложения на определенный момент времени, не дублируя нигде более 
код постоянного хранения. 


® В-третьих, классы модели предметной области и граф наследования можно про- 
ектировать и структурировать в соответствии с той же терминологией и понятия- 
ми, которые используются экспертами в предметной области. Это позволит сфор- 
мировать универсальный язык для программистов и бизнес-экспертов, улучшит 
взаимодействие между ними и повысит вероятность того, что будет создано то, 
что действительно нужно заказчику (программисты, работающие над пакетом бу- 
хучета, могут вообще не понимать, что означает учет по методу начислений, если 
в их коде не используется та же терминология). 


В приложении „МЕТ имеет смысл держать модель предметной области в отдельной 
сборке (например, в отдельном проекте библиотеки классов С# или в нескольких та- 
ких проектах}; это позволит постоянно помнить о различии между моделью предметной 
области и пользовательским интерфейсом приложения. Необходимо иметь ссылку из 
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проекта пользовательского интерфейса на проект модели предметной области. Однако 
ссылок в противоположном направлении быть не должно, потому что модели предмет- 
ной области нет никакого дела до реализации пользовательского интерфейса, которая 
работает с ней. Например, если модели предметной области отправлена неверно оформ- 
ленная запись, то она должна вернуть структуру данных с сообщением об ошибке, об- 
наруженной при проверке достоверности. но не должна пытаться как-то отобразить эту 
опгибку на экране (это работа пользовательского интерфейса). 


Архитектура “модель-представление” 


Если в приложении существует единственное разделение между пользовательским 
интерфейсом и моделью предметной области”, то такая архитектура называется архи- 
тектурой “модель-представление” (рис. 3.1). 


> Обычно 
Запрос ———} | Пользовательский || |. > 
А, сохраняется 
:. БА И аееы в реляционной 
представление 
Ответ (“пред } базе данных 


Рис. 3.1. Архитектура “модель-представление” для веб-приложений 


Она организована намного лучше и проще в сопровождении, чем архитектура Эта 
ОТ, но все равно имеет две существенные слабости. 


® Компонент модели включает массу повторяющегося кода обращения к данным, 
который специфичен для поставщика конкретной используемой базы данных. Он 
переметан с кодом бизнес-процессов и правилами действительной модели пред- 
метной области, заслоняя тот и другой. 


® Поскольку модель и пользовательский интерфейс тесно связаны с платформами 
базы данных и графического пользовательского интерфейса, становится очень 
трудно (если не невозможно) выполнять автоматизированное тестирование того и 
другого или же повторно использовать любую часть этого кода с другой базой дан- 
ных либо другими технологиями графического пользовательского интерфейса. 


Трехъярусная архитектура 


Недостатки предыдущей архитектуры частично устранены в трехъярусной архи- 
тектуре?. В ней код постоянного хранения отделяется от модели предметной области 
и выносится в отдельный третий компонент, который называется уровнем доступа к 
данным (аа ассезз 1ауег — ОАТ) (рис. 3.2]. 


? В данной книге применяется термин модель предметной области, но если вам ближе ва- 
рианты бизнес-логика или бизнес-механизм, то можете использовать их. Версия “модель 
предметной области" выбрана потому, что она перекликается с концепциями предметно- 
управляемого проектирования (об этом речь пойдет позже). 


3 Некоторые полагают, что ее следует называть трехуровневой ({гее-1вуег) архитектурой, 
потому что понятие ярус (Чег) обычно относится к физически разделенным программным 
службам (те. выполняющимся на разных серверах или, по крайней мере, в разных процес- 
сах операционной системы). Однако в данном обсуждении это несущественно. 
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Запрос Пользовательский Уровень |__> Обычно 
интерфейс доступа поддерживается 
Ответ (“представление”) кданным --- реляционной 


базой данных 


Рис. 3.2. Трехъярусная архитектура 


Часто, хотя и не обязательно, уровень РАГ, строится в соответствии с шаблоном 
КВерозйогу (репозиторий), в котором объектно-ориентированное представление храни- 
лища данных служит фасадом, скрывающим реляционную базу данных. Например, 
может существовать класс по имени ОгаегзВероз1+охгу, у которого есть такие методы, 
как СефА11Огаегз() или Ре1ефеОгадег (1п%+ ог4ектТр). Они используют лежащую в ос- 
нове базу данных для извлечения (удаления, обновления и тд.) экземпляров объектов 
модели, которые соответствуют заданному критерию. Если добавить шаблон АБзётгас{ 
Еасогу (абстрактная фабрика), означающий, что модель не будет связана ни с какой 
конкретной реализацией репозитория данных, а вместо этого получать к нему доступ 
только через интерфейсы и абстрактные базовые классы „МЕТ, то модель становится 
полностью отделенной от технологии баз данных. Это значит, что появляется возмож- 
ность легко создавать автоматизированные тесты для проверки ее логики, используя 
фиктивные или имитированные репозитории для симуляции различных условий. В сле- 
дующей главе эта техника будет показана в действии. 

В настоящее время трехъярусная архитектура является одной из наиболее птироко 
распространенных архитектур программного обеспечения. Причина ее популярности 
в том, что она обеспечивает хорошее разделение ответственности, не приводя к чрез- 
мерному усложнению. а также в том, что она не накладывает никаких ограничений на 
реализацию пользовательского интерфейса, а потому отлично совместима с платфор- 
мами графического пользовательского интерфейса, состоящего из форм и элементов 
управления (например, УИпао\з Еоглз или АЗРМЕТ \еЕогилз). 

Трехъярусная архитектура отлично подходит для описания общего дизайна про- 
граммного продукта, но ничего не говорит о том, что происходит внутри уровня поль- 
зовательского интерфейса. Это не слишком хоропто в ситуациях, когда логика, встроен- 
ная в компонент пользовательского интерфейса, начинает разрастаться до огромных 
размеров подобно снежному кому. Так происходит из-за того, что зачастую намного 
быстрее и проще добавить новое поведение непосредственно в обработчик события 
(в духе таг 01, чем выполнить рефакторинг модели предметной области. Когда уро- 
вень пользовательского интерфейса напрямую связан с применяемой платформой гра-. 
фического пользовательского интерфейса (УЯпао\"з Еогиаз, У/еЬКогип$). создание каких- 
либо автоматизированных тестов для него практически невозможно. В результате весь 
новый код, таящий в себе неприятности, избегает какого-либо контроля. Неспособность 
трехъярусной архитектуры обеспечить дисциплину на уровне пользовательского интер- 
фейса в худшем случае приводит к получению приложения в стиле Этагё ОТ с жалкой 
пародией на модель предметной области внутри. 


Архитектура “модель-представление-контроллер” 


Если вы видите. что даже после рефакторинга модели предметной области код поль- 
зовательского интерфейса остается громоздким и сложным, архитектура МУС позволит 
разделить компонент пользовательского интерфейса на две части (рис. 3.3). 
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Обычно 
сохраняется 
- - > вреляционной 
базе данных, 
возможно, 
через 
репозитории 


Запрос 


Контроллер Ша Модель 


Ответ Представление 


НТМЕ 


Модель 
презентации 


Рис. 3.3. Архитектура МУС для веб-приложений 


В рамках этой архитектуры запросы направляются классу контроллера, который 
обрабатывает пользовательский ввод и взаимодействует с моделью предметной облас- 
ти для обработки запроса. В то время как модель предметной области содержит в себе 
логику предметной области (те. бизнес-объекты и бизнес-правила), контроллеры вклю- 
чают логику приложения, такую как навигация по многошаговым процессам или техни- 
ческие детали вроде аутентификации. Когда наступает момент производства видимого 
для пользователя интерфейса, контроллер подготавливает данные, которые должны 
быть отображены (модель презентации, или У1еирафа в АЗРМЕТ МУС, которой может 
быть, например, список объектов Ргодис®, соответствующих запрошенной категории), 
выбирает представление и предоставляет ему выполнить остальную работу. Поскольку 
классы контроллеров не привязаны к технологии пользовательского интерфейса (НТМТ), 
они представляют собой литть простую, тестируемую логику. 

Представления — это простые пгаблоны для преобразования У1еирРака в конечную 
НТМЕ-разметку. Они могут содержать базовую логику. связанную только с презента- 
цией, например, способность прохода по списку объектов для генерации строки НТМТ- 
таблицы для каждого объекта или способность скрывать или показывать раздел стра- 
ницы в соответствии с установленным флагом в У1еирафа, но ничего сложнее этого. 
Обычно проводить автоматизацию тестирования вывода представлений не рекоменду- 
ется (единственный способ мог бы предусматривать проверку специфических шаблонов 
НТМГ, но и он недостаточно надежен), поэтому вывод должен сохраняться насколько 
возможно простым. 

Не пугайтесь, если все это пока кажется неясным; скоро будет приведена масса 
примеров. Если вам сейчас трудно понять, как отделить представление от контролле- 
ра, как это часто бывает в начале изучения архитектуры МУС (скажем, куда поместить 
ТехЕВох — в представление или в контроллер?), то это, скорее всего, потому, что вы 
до сих пор использовали технологии, которые делали такое разделение трудным или 
невозможным, например, те же УЛпао\уз Еоптз или АЗРМЕТ \’еЪЕогиаз. Ответ на вопрос 
о ТехЁВох состоит в том. что вы отныне не должны думать в терминах графических 
элементов пользовательского интерфейса, а только в терминах запросов и ответов, что 
более соответствует модели веб-приложений. 


Реализация в АЗР.МЕТ МУС 


В контексте АЗРМЕТ МУС контроллеры — это классы „МЕТ, обычно унаследованные 
от встроенного базового класса СопЕго11ег. Каждый общедоступный метод класса-нас- 
ледника Сопего11ет называется методом действия; он автоматически ассоциируется 
с ОВЕ в конфигурируемой схеме ОБЕ и после выполнения некоторых операций может 
визуализировать выбранное представление. Механизмы ввода (получения данных из 
НТТР-запроса) и вывода (визуализации представления, перенаправления запроса к дру- 
гому действию и тп.) спроектированы с учетом обеспечения тестируемости, поэтому во 
время реализации и тестирования привязка к какому-либо активному веб-серверу не 
требуется. 
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Хотя и поддерживается выбор механизмов представлений, по умолчанию пред- 
ставлениями будут модернизированные страницы АЗРМЕТ УМ’еЬЕогтз, обычно реали- 
зованные в виде шаблонов АЗРХ (без файлов с классами отделенного кода) и всегда 
свободные от сложностей, связанных с еле и обратными отправками. Шаблоны 
АЗРХ обеспечивают знакомый, обслуживаемый \1зиа1 Зато способ определения НТМГ- 
разметки со встроенным кодом С# для взаимодействия с У1емрафа, предоставленного 
контроллером. 

В АЗРМЕТ МУС реализация модели оставляется полностью на усмотрение разра- 
ботчика. Никакой определенной инфраструктуры для модели предметной области не 
предлагается, поскольку для этого достаточно простой библиотеки классов С#, расити- 
ренных средств „МЕТ, а также выбранной базы данных и кода доступа к данным либо 
инструмента ОКМ. Хотя по умолчанию все новые проекты АЗР.МЕТ МУС включают пап- 
ку по имени /Моае1з, лучше хранить код модели предметной области в отдельном про- 
екте библиотеки классов У!зиа1 Эа. О реализации модели предметной области речь 
пойдет далее в главе. 


История и преимущества 


Понятие “модель-представление-контроллер” существует с конца 1970-х годов и ве- 
дет свою родословную от проекта ЭлаШаК в Хегох РАБС. Изначально оно задумывалось 
как способ организации некоторых первых приложений с графическим пользователь- 
ским интерфейсом, хотя определенные аспекты его значения в наши дни — особенно 
в контексте веб-приложений — несколько отличаются от изначального мира “экранов” 
и “инструментов” ЗтаШаЖ. Например, изначальный дизайн ЭтаШаШ предполагал, 
что представление обновляет себя всякий раз. когда изменяется лежащая в его основе 
модель данных, следуя шаблону ОБзегуег Зупсбгоп1тайоп (синхронизации с наблюда- 
телем), что является бессмысленным, если представление уже визуализировано в виде 
НТМГ-страницы в чьем-то браузере. 

В наши дни сущность шаблона проектирования МУС отлично работает с веб-прило- 
жениями по чследующим причинам. 


® Взаимодействие с приложением МУС следует естественному циклу действий поль- 
зователя и обновлений представления, причем предполагается, что представле- 


ние не имеет состояния, а это хоропто отображается на цикл запросов и ответов 
ТР 


® Приложения МУС стимулируют естественное разделение ответственности. Во- 
первых, это облегчает чтение и понимание кода, а, во-вторых, логика контрол- 
лера отделена от смеси НТМГ-разметки, поэтому большая часть уровня пользова- 
тельского интерфейса приложения может быть субъектом автоматизированного 
тестирования. 


АЗРМЕТ МУС — не первая веб-платформа, следующая архитектуре МУС. Технология 
Киру оп КаП5 также основана на МУС, и хотя она появилась позже других, ее преимуще- 
ства уже доказаны платформами АрасВе Зы. Эрип МУС и многими другими. 


Вариации архитектуры 
“модель-представление-контроллер” 


Вы уже познакомились с ключевой конструкцией приложения МУС, особенно с той, 
которая обычно встречается в АЗРМЕТ МУС. Однако другие интерпретируют МУС ина- 
че, добавляя, исключая или изменяя компоненты в соответствии с областью примене- 
ния и назначением проектов. 
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Расположение кода доступа к данным 


Архитектура МУС не накладывает никаких ограничений на реализацию компонента 
модели. При желании осуществлять доступ к данным можно через абстрактные репози- 
тории (и фактически это будет сделано в примере следующей главы), но это все равно 
соответствует архитектуре МУС, даже если на первый взгляд так не кажется. 


Размещение логики предметной области 
непосредственно в контроллерах 


Взглянув на предыдущую диаграмму (см. рис. 3.3), несложно понять, что нет ника- 
ких строгих правил, которые заставили бы разработчиков корректно разделять логику 
между контроллерами и моделью предметной области. Даже несмотря на то, что по- 
ступать так не следует, вполне возможно, под давлением сиюминутных обстоятельств, 
поместить логику предметной области в контроллер, например, потому, что так проще 
сделать в конкретный момент. Лучший способ противостоять такой недисциплиниро- 
ванности, выражающейся в смепивании модели с контроллером. состоит в том, чтобы 
добиваться хорошего покрытия кода автоматизированными тестами, поскольку даже 
имена этих тестов позволят судить о том, верно или неверно организована логика. 

В большей части демонстрационного кода примеров АЗРМЕТ МУС вообще пренебре- 
гают разделением между контроллерами и моделью предметной области, и это можно 
назвать архитектурой “контроллер-представление". Для реальных приложений такой 
подход нежелателен, так как теряются все перечисленные ранее преимущества модели 
предметной области. Моделирование предметной области рассматривается в последую- 
щих разделах данной главы. 


Архитектура “модель-представление-презентатор” 


Архитектура “модель-представление-презентатор” (Моае]-\Чех-Ргезегцег — МУР) — 
это новая вариация МУС, которая больше подходит для платформ графического поль- 
зовательского интерфейса, хранящих состояние, таких как \УЛодо\з Еолз или АЗРМЕТ 
У’еЬЕогиз. При использовании АЗРМЕТ МУС знать о МУР не обязательно, однако во из- 
бежание путаницы ниже приводятся некоторые пояснения. 

По сути, презентатор (ргезете1 несет те же обязанности, что и контроллер в МУС. 
Однако вдобавок он имеет некоторую связь с представлением. имеющим состояние, не- 
посредственно редактируя значения, которые отображаются в графических элементах 
интерфейса в соответствии с пользовательским вводом (вместо того, чтобы давать воз- 
мозжность представлению визуализировать себя по птаблону). 

Существуют две основных разновидности МУР. 


® Пассивное представление, не имеющее логики, а просто содержащее графические 
элементы пользовательского интерфейса, которыми манипулирует презентатор. 


ы Наблюдающий контроллер, при котором представление может отвечать за опре- 
деленную логику презентации, такую как привязка данных на основе ссылки на 
некоторый источник данных в модели. 


Разница между этими двумя разновидностями довольно субъективна и определяется 
только тем, насколько интеллектуальным должно быть представление. В любом случае 
презентатор отделен от технологии графического пользовательского интерфейса, поэто- 
му его логику легко понять и протестировать с помощью автоматизированных тестов. 

Некоторые утверждают, что модель отделенного кода АЗРМЕТ Ме БЕоги$ подобна 
разновидности МУР с наблюдающим контроллером. в котором разметка АЗРХ — это 
представление, а класс отделенного кода — презентатор. Однако на самом деле стра- 
ницы АЗРХ с их классами отделенного кода настолько тесно связаны между собой, что 
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между ними невозможно просунуть лезвие бритвы. Рассмотрим, к примеру, событие 
ТеепрафаВоппа сетки данных; это ответственность представления. но обрабатывает- 
ся это событие в классе отделенного кода: такой подход явно не соответствует законам 
МУР Существуют способы реализации настоящего дизайна МУР с помощью МеЪЕогтлз, 
обращаясь к иерархии элементов управления только через интерфейс, но это сложно и 
в этом случае придется постоянно “сражаться” с платформой. Многие пытались делать 
это и многие сдавались. 

АЗРМЕТ МУС следует принципам шаблона МУС, а не МУР потому что архитектура 
МУС остается более популярной и она существенно проще для веб-приложений. 


Моделирование предметной области 


Вы уже убедились, что имеет смысл брать объекты реального мира, его процессы 
и правила, описываютцие субъект программного обеспечения. и инкапсулировать их в 
компонент, именуемый моделью предметной области. Этот компонент — сердце вашей 
программы; он составляет его вселенную. Все остальное (включая контроллеры и пред- 
ставления) — просто технические детали, предназначенные для поддержки или обеспе- 
чения взаимодействия с моделью предметной области. Эрик Эванс (Ес Ехап$), лидер 
в области предметно-управляемого проектирования (4отат-апуеп аезют — 205}, вы- 
сказался по этому поводу следующим образом. 


Часть программного обеспечения, которая, в частности. решает задачи из мо- 
дели предметной области, обычно составляет лишь небольицлю часть всей про- 
граммной системы, хотя ее важность непропорциональна ее размеру. Чтобы, 
применить наши умственные способности наилучшим образом, мы должны 
иметь воэможность посмотреть на элементы модели и увидеть их в виде сис- 
темы. Мы не должны выделять их из огромной кучи объектов, подобно поиску 
соэвездия на ночном небе. Нам нужно четко отделить объекты предметной 
области от других функций системы, тогда мы сможем избежать путаницы 
концепций предметной области с концепциями. относящимися только к техно- 
логии программирования, и не потерять из виду предметную область в общей 
массе системы. 


Дотат-Огшеп Рездп: ТаскИипа Сотрехйу т Пе Неа о 5оДиоте, Бу Ейс Еуапз 
(дафзоп-№езюеу, 2004) 


Платформа АЗРМЕТ МУС не содержит никакой специфической технологии, относя- 
щейся к моделированию предметной области (взамен она полагается на то, что унас- 
ледовала от каркаса МЕТ Егате\могК и его “экосистемы”}, поэтому в книге нет главы, 
посвященных моделированию предметной области. Тем не менее, моделирование — это 
М в аббревиатуре МУС, поэтому вообще его проигнорировать нельзя. В следующем раз- 
деле будет показан небольшой пример реализации модели предметной области с помо- 
щью .МЕТ и ОГ Зегует, в котором используются некоторые базовые приемы РОБ. 


Пример модели предметной области 


Наверняка у вас имеется опыт “мозговых штурмов” моделей предметной области в 
прежних проектах. Обычно в этом участвует один или более разработчиков, один или 
более бизнес-экспертов, классная доска и куча печенья. По истечении некоторого вре- 
мени появляется первая черновая модель бизнес-процессов, которые должны быть ав- 
томатизированы. Например, если вы собираетесь реализовать сайт онлайновых аукцио- 
нов, то можно начать с модели, похожей на показанную на рис. 3.4. 
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МетьЬег * 1 
-ГодиМате 


+ВерщабопРой\ $5 


+АЗАЯВ (т гпегтьег, п атоцпё) 


Рис. 3.4. Черновая модель предметной области системы онлайновых аукционов 


Диаграмма показывает, что модель содержит набор участников (Мепъехг}, каждый 
из которых размещает ряд заявок (В19) на предметы торгов (ТЕ еп). На один предмет 
торгов может поступать множество заявок от разных участников. 


Сущности и объекты значений 


В этом примере участники аукциона и предметы торгов — зто сущности, в то время 
как заявки — просто объекты значений. Если вы не знакомы с этими терминами моде- 
лирования предметной области, вот пояснение: сущности характеризуются постоянной 
идентичностью на протяжении их времени жизни, независимо от того, как меняются их 
атрибуты, а объекты значений определяются лишь значениями их атрибутов. Объекты 
значений логически неизменны, потому что любое изменение значения атрибута дает 
совершенно новый объект. Сущности обычно имеют один уникальный ключ (первич- 
ный ключ), тогда как объекты значений в нем не нуждаются. 


Универсальный язык 


Ключевым преимуществом реализации модели предметной области как отдельно- 
го компонента является возможность ее проектирования в соответствии с выбранным 
языком и терминологией. Старайтесь найти и придерживаться четкой терминологии 
для описания сущностей, операций и отношений, которые имеют смысл не только для 
разработчиков, но также и для экспертов в предметной области. Скажем, вам ближе 
понятия пользователи и роли, а экспертам в предметной области — агенты и распро- 
дажи. Даже если вы моделируете концепции, для которых у зкспертов предметной в 
области нет устоявшихся терминов, старайтесь достигнуть с ними соглашения об уни- 
версальном языке. В противном случае не будет уверенности в том, что моделируются 
те же самые процессы и отношения, которые имеют в виду эксперты предметной облас- 
ти. Универсальный язык настолько важен по двум основным причинам. 


® Разработчики естественным образом говорят на языке кода, оперируя термина- 
ми “имя класса”, “таблица базы данных” и тп. Сохранение терминов кода в со- 
гласованном состоянии с терминами, используемыми экспертами в предметной 
области, и терминами, применяемыми в пользовательском интерфейсе приложе- 
ния, гарантирует простоту общения. В противном случае нынешние и будущие 
разработчики с большой вероятностью будут неверно интерпретировать запросы 
о новых средствах или отчеты об ошибках, или же введут в пользователей сту- 
пор, сказав нечто вроде “Пользователь не имеет ассоциированной с ним роли для 
доступа к зтому узду” (что может показаться свидетельством неверно работающе- 
го программного обеспечения) вместо того, чтобы сказать “Агент не имеет права 
доступа к этому документу”. 
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® Это позволяет избежать чрезмерного обобщения программного обеспечения. Мы, 
программисты, имеем склонность моделировать не только конкретную бизнес-ре- 
альность, но любую возможную реальность (скажем, в примере с аукционом заме- 
нять “участников» и “предметы торгов” общим понятием “ресурсов”, связанных не 
“заявками”, а “отношениями”). Пренебрегая ограничением модели предметной об- 
ласти теми же пределами, которыми ограничен конкретный бизнес в конкретной 
отрасли, вы отвергаете возможность понимания его работы, и в будущем обрекаете 
себя на реализацию средств, которые будут выглядеть как неуклюжие частные слу- 
чаи в вашем злегантном метамире. Ограничения не лимитируют но направляют. 


В случае необходимости будьте готовы к рефакторингу модели предметной области. 
Эксперты в ООО говорят, что любое изменение в универсальном языке означает из- 
менение в программном обеспечении. Если вы позволите программной модели не со- 
ответствовать текущему пониманию предметной области, принудительно транслируя 
концепции на уровне пользовательского интерфейса, то, несмотря на внутреннее сопро- 
тивление, ваш компонент модели станет причиной пустой траты усилий разработчи- 
ков. Помимо того, что это станет притягивать к себе оштибки, зто также может означать, 
что некоторые запросы реализации соверитенно простых вещей станут исключительно 
трудными в реализации, и вы не сможете объяснить зто клиентам. 


Агрегаты и упрощение 


Давайте еще раз взглянем на диаграмму примера с онлайновым аукционом (см. 
рис. 3.4). В том виде, как она есть, она не слишком помогает в реализации на С# и 
ЭСТ, Зегуег. При загрузке участника в память следует ли также загружать все его заявки 
и все предметы, ассоциированные с этими заявками, а также прочие заявки на те же 
предметы вместе со всеми подавшими заявку на них участниками? При удалении чего- 
либо насколько глубоко должно распространяться удаление по графу объектов? При же- 
лании определить правила достоверности, включающие отношения между объектами, 
куда следует поместить эти правила? И это лишь тривиальный пример — насколько же 
все может оказаться сложнее в реальном мире? 

Предлагаемый ООО способ преодоления зтой сложности состоит в распределении 
сущностей предметной области по группам, именуемым агрегатами. На рис. 3.5 пока- 
зано, как это можно сделать в примере с аукционом. 


+АнсвопЕПаБае 
+АЗАЕА( т тетрег, п атоцп 


$ 


Рис. 3.5. Модель предметной области аукциона с агрегатами 
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Каждый агрегат имеет корневую сущность, которая определяет идентичность всего 
агрегата и действует как “босс” агрегата в целях проверки достоверности и постоянного 
хранения. Когда речь идет об изменении данных, агрегат представляет собой единый 
модуль, позтому выбирайте агрегаты, которые связаны логически с реальными бизнес- 
процессами, те. наборы объектов, которые имеют тенденцию изменяться группами (тем 
самым углубляя описание модели предметной области). 

Объекты вне определенного агрегата могут хранить только постоянные ссылки на 
корневую сущность. но не на любой другой объект внутри агрегата (фактически значе- 
ния идентификаторов для некорневых сущностей даже не обязаны быть уникальными 
за пределами контекста их агрегата}. Это правило заставляет трактовать агрегаты как 
атомарные узлы и гарантирует, что изменения внутри агрегата не станут причиной по- 
вреждения данных где-либо еще. 

В данном примере “участники” и “предметы” являются корневыми сущностями агре- 
гатов, так как они должны быть доступны независимо друг от друга, тогда как “заявки” 
интересуют нас лишь в контексте “предмета”. Заявки могут содержать ссылки на участ- 
ников, но участники не имеют прямых ссылок на заявки, потому что иначе зто наруши- 
ло бы границы агрегата предмета торгов. Сохранение отношений однонаправленными, 
насколько это возможно, приводит к существенному упрощению модели предметной 
области и может дать дополнительное представление о предметной области. Если вы 
привыкли воспринимать схему базы данных ЗОГ, как модель предметной области, то 
это может показаться незнакомым (учитывая, что все отношения в базе данных ЗОГ. 
являются двунаправленными), но С# может моделировать более широкий диапазон 
концепций. 

Представление нашей модели предметной области в ее нынешнем виде. выраженное 
на С#, выглядит так: 


рч611с с1азз Мепрек 

{ 
рчЮ11с зЕк1пд Год1пМаше { деё; зек; } // Уникальный ключ 
роЮ11с 1пЕ ВерибаЕ1опРо10ез { деф; зеф; } 

} 


руЬ11с с1азз Тем 
{ 
рор11с 4пЕ ТЕештр { деё; рг1уаке зеё; } // Уникальный ключ 
раЮ11с зЕг1ра Т1Е1е { деё; зе; } 
руЮ11с зЕг1ра Безсг1рё1оп { деЕ; зе®; } 
рию11с Рафетлме АпсЕ1олЕпаРаее { деф; зе®; } 
рою11с 11136<819> В19$ { дее; рглуафе зеф; } 
} 


руЮ11с с1азз В1а 


{ 
рур11с Меньек Мепфег { деё; рг1уаее зеф; } 
руб11с РатеТ1ме РафеР1Тасея { де; рг1уате зе; } 
рор11с Чес1та1 В1АЯАпоное { деё; рге4фуафе зек; } 

} 


Обратите внимание, что класс В14 неизменен (что свойственно настоящим объек- 
там значений)^, а свойства других классов надлежащим образом защищены. Эти клас- 
сы соблюдают границы агрегатов в том, что никакие ссылки не пересекают их. 


* При желании можно переопределить операцию эквивалентности и трактовать два экземпляра 
как равные, когда равны все их атрибуты, но в рассматриваемом примере это не обязательно. 
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На заметку! В известном смысле структура (зЕгисе)} в С# неизменна (в противоположность 
классу (с1аз3)), поскольку каждое присваивание создает новый зкземпляр, позтому мутации 
не затрагивают других экземпляров. Однако для объекта-значения предметной области это 
не всегда та неизменность, которая нужна; часто требуется предотвратить любые изменения 
любых экземпляров (после точки их создания), а это означает, что все их поля должны быть 
доступны только для чтения. В этом случае класс столь же хорош, как и структура, кроме того, 
класс еще и предоставляет ряд преимуществ (например, поддерживает наследование). 


Ценность определения агрегатов 


Агрегаты привносят в сложную модель предметной области некую суперструктуру, 
добавляя новый уровень управляемости. Это облегчает определение и соблюдение пра- 
вил целостности данных (корень агрегата может контролировать состояние всего агре- 
гата). Они предоставляют естественную единицу хранения, что позволяет легко решить, 
какую часть графа объектов загружать в память (возможно, используя отложенную за- 
грузку ссылок на корни других агрегатов}. Они также служат естественной единицей 
каскадного удаления. И поскольку изменения данных являются атомарными в пределах 
агрегата, он представляет собой естественную единицу для транзакций. 

С другой стороны, агрегаты накладывают ограничения, которые иногда могут по- 
казаться искусственными — каковыми они и являются — и нарушение их болезненно. 
Они не являются “родной” концепцией для ЗОГ, Зегуег, как и для большинства инстру- 
ментов ОБМ, поэтому для правильной их реализации команде потребуется дисциплина 
и эффективное общение. 


Сохранение кода доступа к данным в репозиториях 


Рано или поздно вам придется подумать о помещении и извлечении объектов пред- 
метной области в некоторого рода постоянное хранилище — обычно в реляционную базу 
данных. Разумеется, эта ответственность возлагается на современные программные 
технологии и не является частью моделируемой предметной области. Постоянство — 
независимая ответственность (настоящие архитекторы употребляют термин ортого- 
нальная ответственность — зто звучит более веско}, поэтому вы не должны смеши- 
вать код, обслуживающий постоянное хранение, с кодом модели предметной области; 
не должны встраивать код доступа к базе данных непосредственно в методы сущностей 
предметной области; и не должны помещать код загрузки или запросов в статические 
методы тех же классов. 

Обычный способ обеспечить чистоту такого разделения состоит в определении ре- 
позиториев. Это ни что иное, как объектно-ориентированное представление лежащего 
в основе хранилища — реляционной базы данных (или файлового хранилища), данных, 
доступных через веб-службу, и тп., — служащее фасадом для реальной реализации. При 
работе с агрегатами вполне нормально определять отдельный репозиторий для каждого 
агрегата, потому что агрегаты являются естественными единицами логики постоянно- 
го хранения. Например, продолжая пример с аукционом, можно определить следующие 
два репозитория (обратите внимание. что в В1ЯзВероз1{огу необходимости нет, так как 
заявки должны находиться только по ссылкам от зкземпляров предметов): 


рою11с с1азз МепшрехзВероз1фоку 

{ 
ру611с у01а АЯЯМепьек (Метъехг мешьег) { /*х Реализовать */ } 
рою11с Мешьег РессввВуоч10Мате (зг1п9 1091пМаше) { /* Реализовать */ } 
руБ11с уо1Я ЗиБи1ЕСВапдез() { /* Реализовать */ } 
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руб11с с1аз$ ТеепзВероз1когу 
{ 
руЮ11с уо1@ АЯЯТеет (ТЕеш 1Еет) { /х Реализовать */ } 
рию11с ТЕеш ЕефесьВутр (1пе 1+еттр) { /*х Реализовать */ | 
риуб14с П15зЕ<ГЕем> 
ТУзЕТЕет$з (10 раде51хе,1пЕ радеТпдех) { /* Реализовать */ } 
рыр11с уо1а бабт1ЕСВардаез () { /* Реализовать */ } 
} 


Обратите внимание, что репозитории связаны только с загрузкой и сохранением 
данных и содержат минимально возможный объем логики. В зтой точке можно за- 
полнить кодом каждый метод репозитория, используя выбранную стратегию доступа 
к данным. Можно было бы вызывать хранимые процедуры, но в этом примере будет 
показано, как облегчить решение задачи за счет применения инструмента ОКМ (ИМО 
фо 590). 

Мы будем исходить из того, что репозитории смогут самостоятельно определять, ка- 
кие изменения они должны сохранять при вызове 5и51ЕСнапдез () (запоминая, что 
было сделано над ранее возвращенными сущностями — ТЛМО ю ЗОГ и МНегпае легко 
справляются с этим}. Взамен можно было бы передавать специфические обновленные 
сущности, скажем, методу бауеМепьех (мепоек) ‚ если зто выглядит проще для выбран- 
ного способа доступа к данным. 

И, наконец, получить максимум дополнительных преимуществ от репозиториев 
можно, определив их абстрактно (те. в виде интерфейсов МЕТ) и обращаясь к ним че- 
рез шаблон АБзтасё Еасюгу (абстрактная фабрика} либо через контейнер Гпрегзюоп о] 
Согито] (юС) {инверсия управления). Это облегчит тестирование кода, зависящего от по- 
стоянного хранения: можно будет просто подставлять фиктивные или имитированные 
реализации, которые эмулируют любое необходимое состояние модели предметной об- 
ласти. Также упростится замена одной реализации репозиториев другими, если позднее 
будет принято решение перейти на другую базу данных или другой инструмент ОВМ. 
Примеры применения ТС с репозиториями будут приведены далее в этой главе. 


Использование ЦМО то $01 


М9 ю ОГ был представлен МсгозоЁ как часть МЕТ 3.5 в 2007 г Назначение это- 
го инструмента в том, чтобы предоставить строго типизированное МЕТ-представление 
схемы базы данных и содержащейся в ней информации. В результате значительно со- 
кращается объем кода, который приходится писать в распространенных сценариях дос- 
тупа к данным, и отпадает необходимость создания и сопровождения хранимых проце- 
дур для каждого тина запросов, которые нужно выполнять в приложении. Несмотря на 
то что зтот инструмент ОКМ пока еще не настолько зрел и развит, как его конкуренты 
вроде МНегпаце, он иногда проще в применении, учитывая полную поддержку техно- 
логии ИМО и исчерпывающую документацию. 


На заметку! В последние месяцы многие комментаторы выражают опасение по поводу того, что 
Мсгозой может объявить ЧМО 0 5С1. устаревшим в пользу ЕпМу ЕгатемогК. Однако ходят слу- 
хи, что ЦМО {о 5О1 будет включен и получит новое развитие в .МЕТ 4.0, потому зти страхи, по 
крайней мере, отчасти, не обоснованы. Поскольку АЗРМЕТ МУС не зависит от ЦМО ю ЗО[, вы 
вольны применять вместо него альтернативные ОВМ (например, популярный МНЮегпае}. 


В большинстве демонстраций 11М© тю ЗОГ, используется в качестве инструмента бы- 
строго прототипирования. Начните с существующей схемы базы данных и в редакторе 
\У1впа! Эёлаю перетащите таблицы и хранимые процедуры на полотно. 
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Инструмент ГЛМО 1ю ЗОГ. автоматически сгенерирует соответствующие классы и ме- 
тоды сущностей. Затем внутри кода С# с помощью запросов ТЛМ@ можно извлекать эк- 
земпляры зтих сущностей из контекста данных (он преобразует запросы Г.1\© в ЗОГ во 
время выполнения}, модифицировать их в коде С#. а затем вызвать 5о6т1ЕСВапдез () 
для записи изменений обратно в базу данных. 

Это блестяще подходит для приложений Эта ОТ, но для многоуровневых архитек- 
тур существуют ограничения. Начиная со схемы базы данных, а не с объектно-ориенти- 
рованной модели предметной области, вы тем самым отказываетесь от ясного дизайна 
модели предметной области. 


Что такое рафабСолеехЕ? 


Объект контекста данных РафаСопЕехЕ — зто точка входа в АР!-интерфейс ИМО ® $501. Ему 
известно, как загружать, сохранять и запрашивать любой тип „МЕТ, который имеет отображение 
в ЦМО ю $0 (и который можно добавлять вручную или с помощью визуального конструктора). 
После загрузки объекта из базы данных Раф аСоп+ех+ отслеживает любые изменения, проводи- 
мые в свойствах этого объекта. Сохранить зти изменения обратно в базу данных можно, вызывая 
его метод ЗиБи1ЕСЪападез (). Это легковесный объект (т.е. недорогой в конструировании); он 
может управлять собственным подключением к базе данных, открывая и закрывая его по мере 
необходимости; и он даже не требует помнить об обязательном его закрытии или уничтожении. 


Существует много разных способов применения ММО тю 5ОГ, и некоторые из них 
перечислены в табл. 3.1. 


Таблица 3.1. Возможные способы применения ИМО №ю $01 


Подход к Рабочий поток Преимущества Недостатки 

проектированию 

Сначала схема, С помощью графического конст- Это удобно, если Вы получаете плохо инкапсули- 

затем генерация руктора ИМО \ю ЭСЕ перетащите вам нравится рованную модель предметной 

кода на полотно таблицы и хранимые проектировать области, которая открывает 
процедуры и позвольте ИМО ю схемы в СЕ Зегуег устройство постоянного хра- 
ЗСЕ сгенерировать классы и объ- Мападетеге Зи. нения всем (например, по 
екты контекста данных из сущест- умолчанию показываются все 
вующей схемы базы данных. Не требует конфигу- идентификаторы базы данных, 

рации отображения. — ивсе отношения являются 
двунаправленными). 


Внастоящее время отсутствует 
поддержка обновления схемы 
базы данных. Единственный 
способ обновления состоит в 
удалении классов ИМО 1ю ЗС и 
создании их заново с потерей 
всех изменений, касающихся 
доступности полей или направ- 
ления отношений. 
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Окончание табл. 3.1 


Ум— 
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Подход к 
проектированию 


Рабочий поток 


Преимущества 


Недостатки 


Сначала код, затем 
генерация схемы 


Создайте ясную объектно-ориен- 
тированную модель предметной 
области и определите интерфей- 
сы для ее репозиториев (в этот 
момент можете написать модуль- 
ные тесть). Затем сконфигурируй- 
те отображения ЦМО то 501, либо 
добавив специальные атрибуты 
кклассам предметной области, 
либо подготовив конфигураци- 
онный файл ХМУ. Сгенерируйте 
соответствующую схему базы дан- 
ных, вызвав уоикратаСопеехе. 
Сгеаферафаразе (). Реализуйте 
конкретные репозитории, написав 
запросы к объекту РатаСопеехе. 


Вы получаете 
ясную объектно- 
ориентированную 
модель с правиль- 
ным разделением 
ответственности. 


Отображения приходится созда- 
вать вручную. 


Не существует встроенного 
метода обновления схемы базы 
данных в процессе. После каж- 
дого изменения схемы необ- 
ходимо удалять базу данных и 
генерировать новую, теряя все 
данные”. 


Подобным образом могут быть 
сгенерированы не все аспекты 
базы данных 5% (например, 
триггеры). 


Сначала код, затем 


Следуйте подходу “сначала код, 


Вы получаете 


Отображения приходится созда- 


ручное создание затем генерация схемы”, но не ясную объектно- вать вручную. 
схемы вызывайте уоитрафаСопеехе. ориентированную 
Стеатератаразе (). Вместо модель с правиль- Синхронизация отображений и 
этого создайте вручную соответ- ным разделением схемы базы данных также долж- 
ствующую схему базы данных. ответственности. на производиться вручную. 
Очевидные способы 
обновления схе- 
мы базы данных в 
процессе. 
Две модели Создайте ясную объектно-ориен- Вы получаете Понадобится писать дополни- 
предметной тированную модель предметной ясную объектно- тельный код для преобразования 
области области и соответствующую ей ориентированную между двумя моделями пред- 


схему базы данных. С помощью 
графического конструктора ИМО {о 
ЗСЕ перетащите на полотно табли- 
цы базы данных, сгенерируйте вто- 
рой независимый набор классов 


модель с правиль- 
ным разделением 
ответственности. 


Не требуется при- 


метной области. 


Нельзя использовать средство 
отслеживания изменений ИМО ю 
ЗЕ: любые изменения в чистой 


сущностей предметной областив — менение атрибутов — модели предметной области 
другом пространстве имен, и по- отображения ЧМО ю — необходимо вручную реплици- 
метьте их все как {пеехпа1. ЗСЕ или конфигура- — ровать в модель предметной 
В реализациях репозиториев ции ХМЕ. области ИМО 1ю 501. 


запросите сущности ИМО тю ЗОЕ 
и затем вручную преобразуйте ре- 
зультаты в экземпляры из модели 
предметной области. 


Как и при подходе “сначала 
схема, затем генерация кода”, 

в случае любых изменениях 
схемы базы данных все дополни- 
тельные специальные настрой- 
ки конфигурации ЧМО 1ю 501 
теряются. 


—Ш 


`В качестве альтернативы можно пользоваться инструментами сравнения/синхронизации схем баз дан- 
ных от независимых поставщиков. 
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Тщательно взвесив все “за” и “против”, предпочтение (в нетривиальных приложени- 
ях} отдается подходу “сначала код, затем ручное создание схемы”. Он не особенно ав- 
томатизирован, однако после некоторого привыкания не требует много работы. Далее 
будет показано, как с помощью этого подхода можно построить модель предметной об- 
ласти и соответствующие репозитории для примера с аукционом. 


Реализация модели предметной области для примера с аукционом 


С помощью ГМО то ЗОГ, можно устанавливать отображения между классами С# и 
схемой базы данных, либо декорируя классы специальными атрибутами, либо создавая 
конфигурационный файл ХМГ. Преимущество варианта с файлом ХМГ. состоит в том, 
что артефакты постоянного хранения полностью удаляются из классов предметной об- 
ласти?, а недостаток — что это не слишком очевидно на первый взгляд. Для простоты 
пойдем на компромисс и воспользуемся атрибутами. 

Ниже приведен код классов модели предметной области, полностью помеченных для 
ЛМО@ © $01: 


118$1па бузвещ; 
13119 Зузсем.Со11есЕ1от$.Сепег1с; 
115119 бузЕеш.Ь1па; 
15104 Зузсеш.Раба.Т1ра.Марр1па; 
03109 бузсем.Раба.Ъ1па; 
[ТаБ1е (Мате="Мепоегз") ] роб11с с1азз Мепюех 
{ 
[Сотишл (ТзРг1иагуКеу=Екие, ТзОЬСепегаеед=Ехгае, Аикобупс=Аюобупс.ОпТпзег®) ] 
1псегкпа1 10Е Мепфехтр { дее; зеё; } 
[Со1итп] риуб11с зЕтг1пд Год1пМаше { де; зе®; } 
[Со1иата] руб11с 116 ВерибаЕ1опРо1тез { ее; зеф; } 
} 
[Таб1е (Маше = "Теетз")] риб11с с1азз Тем 
{ 
[СоТипп (ТзРеПлагуКеу=Екие, Т5ОЮбепекасея=Егае, Ацбобупс=Анбобупс .ОпТизег®) ] 
руБ11с 1пе теештр { дее; 1пегпа1 зе; } 
[Сотамп] руб11с зЕг1па Т1ЕТе { деЕ; зе; } 
[Сом] рыуб11с зЕгапа Резскёрелоп { де; зет; } 
[Со1ишп] роБ11с РабеТ1ме АссЕЗопЕпаРаее { деё; зе®; } 
[Аззостае1оп (ОЕТегКеу = "тЕештр") ] 
рг1уаее ЕпЕ1еубеЕ<В1а> 19$ = пем ЕпЕ1еубее<в19> (); 
руБ11с 111$Е<В14> В145$ { дет { гебаго _Ъ195.Тоь15%() .АзВеааОп1Ту(); 12} 
} 
[ТаБ1е (Маше = "В1аз")] рир11с с1азз В1а 
{ 
[Со1аща (ТзРхаЯтахуКеу=Екие, Тз0Ъбепегафед=егие, Алфобупс=АибоЗупс .ОпТпзеге) ] 
Чптегпат 106 Влатр { дее; зеф; } 
[Со1имп] 1пегпа1 11 Тфештр { деф; зе; } 
[Со1атп] руб11с РабеТ1ме РафеР1асеа { деё; 1псегкпа1 зе; } 
[Соит] руб11с Я9ес1та1 В1ЯАмоцое { дее; 1ифегра1 зе; } 
[Со1имп] 1п6егпа1 10 Мешфектр { дее; зеф; } 
1птегпа1 Епе1ЕуВеЕ<Мепбех> пепфег; 
[АззостаЕ оп (ТВ15Кеу = "МетрегТтО", 5фогхаде = " пепБег") ] 


5 Многие практики ООО стремятся избавить сущности предметной области от любых упоми- 
наний постоянного хранения (например, базы данных). Цель можно сформулировать как 
игнорирование постоянства — еще один пример разделения ответственности. 


6 Чтобы код компилировался, проект должен иметь ссылку на Зузеен.Рафа.1114. 911. 
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руб11с Мешрег Метьет { 
деЕ { гебагп пепрек.ЕпЕ1еу; } 
10сегпа1 зеф { _мешрег.Епе1у = уа1ае; Метшбектр = уа1оае.Метюегтр; } 


} 
Ниже приведено несколько замечаний по этому коду. 


® В некоторой степени нарушается чистота объектно-ориентированной модели 
предметной области. В идеальном мире артефакты 1ЛМ№О ю $ОГ, не должны по- 
являться в коде модели предметной области. потому что ММО ® $01, не является 
средством самой предметной области. Имеются в виду не атрибуты (например, 
[Со1лаил 1), поскольку они больше похожи на метаданные, чем на код. Для сохра- 
нения ассоциаций между сущностями нужно также использовать ЕпЕ1еуВеЕ<тТ> 
и ЕпЕ1тузее<Т> — специальный способ, которым 11МО тю ЗОТ, описывает ссыл- 
ки между сущностями, поддерживающими отложенную загрузку (те. извлечение 
ссылаемых суптиостей из базы данных только по необходимости). 


® ВИМО ® 5ОГ каждый объект предметной области должен быть сущностью с пер- 
вичным ключом. Это значит, что значения идентификаторов требуются для всего, 
даже для В19, которому идентификатор вообще-то не нужен. Таким образом. В1а 
является объектом значения только в том смысле, что он неизменен. Аналогично, 
в объектной модели любой внешний ключ в базе данных должен отображаться на 
[Со1ишп], позтому к В1а потребуется добавить Теештр и МепЪектр. К счастью, 
такие значения идентификаторов можно пометить как 1пеегпа1, чтобы они не 
были видны извне уровня модели. 


® Вместо использования Мепфег. Тод1пМаше в качестве первичного ключа был до- 
бавлен новый искусственный первичный ключ (МепЪегтр}. Он пригодится, если 
вдруг придется менять регистрационные имена. Опять-таки, он может быть поме- 
чен как 1п6етгпа1, поскольку для остальной части приложения он не важен. 


® Коллекция ТЕеп.В19$ возвращает список в режиме только для чтения. Это жиз- 
ненно важно для правильной инкапсуляции. Оно гарантирует. что любые измене- 
ния в коллекции В19$ производятся через код модели предметной области, кото- 
рый обеспечивает соблюдение определенных бизнес-правил. 


® Несмотря на то что в этих классах не определено никакой логики предметной об- 
ласти (это просто контейнеры данных), они по-прежнему являются подходящим 
местом для ее размещения (например, метод АЗав:а () в Тееп). Просто пока этой 
логики не было. 


Если требуется. чтобы система создавала соответствующую схему базы данных ав- 
томатически, можете организовать зто, добавив несколько строк кода: 


РафаСопеехЕ ас = пеи ратаСопЕехЕ (соппесЕ1оп5Ет1п9); // Получить актуальный 
// РабаСопеехе 


9с.СееТар1е<Метрег> (); // ас будет отвечать за хранение объектов класса Метьег 
Чс.СесТар1е<Т+ещ> (); // ас будет отвечать за хранение объектов класса Тем 
Яс.СесТтаЬ1е<в14> (); // ас будет отвечать за хранение объектов класса ва 
Яс.СгеаЕерафаЪазе (); // ас будет издавать команды СВЕАТЕ ТАВТЕ для каждого класса 


Помните, однако, что любые будущие изменения схемы придется выполнять вруч- 
ную, потому что Сгеакератаразе() не может обновить существующую базу данных. 
В качестве альтернативы можно просто создать схему вручную с самого начала. В лю- 
бом случае, как только соответствующую схему базы данных создана, появится возмож- 
ность создавать, обновлять и удалять сущности с использованием синтаксиса Ы\МО и 
методов класса бузЕет.Пафа.Ъ+па.РафаСопфех+. 
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Ниже приведен пример конструирования и сохранения новой сущности: 


РафаСопЕехЕ 4с = пем РафаСопеех® (соппес®1оп5г1п9а); 
ас.СеЕТаБ1е<Мепъег> () .ТизегЕОрборюи1 (пем Мепег 


Тод1пМаме = "бееуе", 
ВерикаЕ1опРо1пез = 0 


р; 
ас.ЗиБи+ЕСВападез (); 


А вот пример извлечения списка сущностей в определенном порядке: 


РафаСопеехЕ ас = пем РабаСопфехЕ (соппес®1оп5%г119); 


уаг шепъег= = Егом м 1п ас.СесТар1е<Мептъекг> () 


Далее в главе вы получите болыше сведений о внутреннем устройстве запросов ММ@ 
и новых средствах языка С#, которые поддерживают их. А пока вместо того, чтобы раз- 
брасывать код доступа к данным по всему приложению, давайте реализуем некоторые 


огдегЬу п.ВериваЕ1опРо1пе5 ЧезсепЯ1т9 
зетесё м; 


ГогеасВ (Мепъек ш 1п пепъегз) 
Сопзо1е.Ит1еер1 пе ("Маще: {0}, Ро+пез: {1}", м.Тоб1оМаше, п.ВеробаЕ1опРо1тез); 


репозитории. 


Реализация репозиториев для примера с аукционом 


Теперь, когда отображения ИМО  $ОГ настроены, предоставить полную реализа- 


цию упомянутых ранее репозиториев достаточно просто: 


риБ11с с1азз Мепьег=Вероз1огу 


{ 


} 


рк1уабе Тар1е<Меньег> мепьегзТа Бе; 
рую11с МеньехзВероз1Еоку (31119 соппесЕ1оп5г1п9а) 


{ 


} 


петъегзТаЪ1е = пем РафаСорфехе (соппес®1оп$ег1па) .сееТаБ1е<Мепшьек> (); 


роб11с уо1а АЯаМепрег (МешЪет шепфек) 


{ 


} 


пепьегзТаЪ1е .ТипзегОпбиыи1 (шепфег); 


ру611с уо1а 5абт1ЕСвападез () 


{ 


} 


пешехзТаб1е .Сопеехе. Заби1ЕСВападез (); 


рур11с Меньег геесЬВу1од91пМате (5119 1091пМате) 


{ 


} 


// Если этот синтаксис не знаком, обратитесь к 
// объяснению лямбда-методов в конце главы. 
тефигп мешьегзТаб1е.Е1кзЕОтреЕаз14 (и => ш.о91пМаше == 1091пМате); 


рую11с с1азз ТеетзВеро$1®огу 


{ 


рк1уаЕе ТаБ1е<Теет> 1%ещзТаю1е; 
раБ11с ТЕемшзВероз1еогу ($65119 соппесЕ1о1$ег119) 


{ 


РафаСопеехе Яс = пеи БабаСопеехе (соппес®1оп5%г119); 
1ЕепзТаб1е = ас.сСееТаб1е<теем> (); 
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РУБ11с 1115Е<Тееш> Р1зЕ1сет$ (102 радеб1те, 11 радеТпаех) 
{ 

тесигп 1сетзТа1е.5К1р (радеб1хе * расе1паех) 

.ТаКе (радеб1те) .Тот1з%(); 

} 
рую11с уо1а зиби1еСвапдез () 
{ 

1сешзТа1е .Сопфехе . би 5т1ЕСвапаез (); 
} 


ручЮ11с уо1а Адатеем(Тфеш 1%ем) 
{ 
1{тетзТаБ1е .ТазегеОпбибите (15ещ); 
} 
риЮр11с ТЕеш геесЬВутр (1пе 1%кептр) 
{ 
тебиги 1сетзТаБ1е.Е1из®ОгреЕаи1+ (1 => 1.теештр == 1ештр); 


} 


Обратите внимание, что эти репозитории принимают в качестве параметра конст- 
руктора строку соединения и затем создают собственный объект расаСоп+ех+. Этот 
шаблон “по контексту на каждый репозиторий” означает что экземпляры репозитория 
не будут взаимодействовать друг с другом. нечаянно сохраняя чужие изменения. либо 
откатывая их. Передача строки соединения в качестве параметра конструктора очень 
хорошо работает с контейнером 1оС; далее в этой главе будет показано, как задать па- 
раметры конструктора в конфигурационном файле. 


Теперь взаимодействовать с хранилищем данных можно через репозиторий: 


ТеетзВероз1®еогу 1%ешзВер = пен ГеетзВероз1согу (соппесе1ой5егк1по); 
1сепзВер.Адатееп (пеи Тъет 
{ 
Т1Е1е = "Рк1уахе де\", 
АисстопЕпараее = веи РасетТ1ше (2012, 1, 1} р 
Резсттретоп = "Ваш шанс иметь собственный самолет." 
}); 
1тешзВер. биб1 сСвапдез (); 


Построение слабо связанных компонентов 


Уровни являются распространенной метафорой для архитектуры программного 
обеспечения (рис. 3.6). 


Уровень 1 


т 


Уровень п 


Рис. 3.6. Многоуровневая архитектура 
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В этой архитектуре каждый уровень зависит только от уровней, расположенных 
ниже — в том смысле, что каждый их них знает о существовании и может иметь доступ 
только к коду на своем уровне и уровнях, расположенных ниже. Обычно верхним уров- 
нем является пользовательский интерфейс, средние уровни обрабатывают концепции 
предметной области, а нижние уровни обеспечивают постоянство данных и прочие об- 
щие службы. Ключевое преимущество такой архитектуры заключается в том, что при 
разработке кода каждого уровня можно забыть о реализации других уровней и думать 
только об АР-интерфейсе, который предоставляется выше. Это позволяет справиться 
со сложностью, характерной для крупной системы. 

Метафора “слоеного пирога” удобна, но есть и другие способы мышления при проек- 
тировании программного обеспечения. Рассмотрим альтернативу, в которой программ- 
ные части представляются в виде компонентов печатной платы (рис. 3.7). 


Рис. 3.7. Пример применения метафоры печатной платы для программных компонентов 


Компонентно-ориентированный подход к проектированию немного более гибок, чем 
многоуровневый подход. В соответствии с этим образом мышления, мы не указываем 
местоположение каждого компонента в “пироге”, а вместо этого подчеркиваем самодос- 
таточность каждого компонента и взаимодействие его с другими только по четко оп 
ределенным интерфейсам. 

Компоненты никогда не делают никаких предположений относительно внутренне- 
го устройства другого компонента: они рассматривают каждый компонент как черный 
ящик, который четко выполняет один или более публичных контрактов (примером могут 
служить интерфейсы „.МЕТ), подобно тому, как микросхемы на печатной плате не знают 
внутреннее устройство друг друга, соединяются между собой с помощью стандартных 
разъемов и птин. Чтобы предотвратить нежелательные сильные связи, каждый программ- 
ный компонент вообще не должен знать о существовании других конкретных компонен- 
тов; он должен знать только интерфейс. выражающий функциональность, но ничего — о 
внутреннем устройстве. Это нечто большее, чем инкапсуляция; это слабая связь. 

Рассмотрим очевидный пример. Предположим, что задача связана с отправкой со- 
общения по электронной почте. Первым делом, вы создаете компонент “отправитель 
электронной почты” с абстрактным интерфейсом. Затем вы присоединяете его к модели 
предметной области либо к другому служебному компоненту (не беспокоясь о том, где 
именно в стеке он находится). После этого можно будет легко подготовить тесты модели 
предметной области, используя макетную реализацию интерфейса отправителя элек- 
тронной почты. а в будущем заменить реализацию отправителя другой, если изменится 


инфраструктура ЭМТЕ. 
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Репозитории — это просто другой тин служебных компонентов, так что наличие спе- 
циального уровня “доступа к данным”. в котором бы они содержались, не требуется. Не 
имеет значения, как компонент-репозиторий выполняет запросы на загрузку, сохране- 
ние или опрос данных — он просто должен реализовывать некоторый интерфейс, опи- 
сывающий доступные операции. С точки зрения потребителя любая другая реализация 
того же контракта столь же хорогта, независимо от того, хранит она данные в базе, в 
двумерных файлах, получает их через веб-службы или как-то еще. Взаимодействие че- 
рез абстрактные интерфейсы вновь возрождает разделение компонентов — не только 
технически, но также в сознании разработчиков. реализующих их средства. 


Стремление к сбалансированному подходу 


Компонентно-ориентированный подход к проектированию не исключает многоуров- 
невого решения (можете сохранять многоуровневую структуру графа компонентов, если 
это помогает), и не все должно представлять абстрактный интерфейс — например, это 
не должен делать пользовательский интерфейс, поскольку от него уже ничего не будет 
зависеть. Аналогично, в неболыших приложениях АЗРМЕТ МУС, при наличии достаточ- 
ной логики в модели предметной области для обеспечения сопровождения всех интер- 
фейсов, можно не выделять контроллеры из модели предметной области. Однако почти 
наверняка получится выигрыпт от инкапсуляции кода доступа к данным и служб внут- 
ри абстрактных компонентов. 

Применяйте гибкий подход; выбирайте то, что лучше всего работает в каждом кон- 
кретном случае. Помните, что в отличие от простого многоуровневого дизайна, в ко- 
тором каждый уровень тесно связан с одной, и только одной конкретной реализацией 
каждого нижележащего уровня, разбиение на компоненты стимулирует инкапсуляцию 
и проектирование по контрактам кусочка за кусочком, что ведет к более простым и тес- 
тируемым решениям. 


Использование инверсии управления 


Компонентно-ориентированное проектирование тесно связано с 10С. Инверсия 
управления — 10С — это шаблон проектирования программного обеспечения, который 
помогает отделять компоненты приложения друг от друга. С 1оС связана. одна пробле- 
ма — название’. Оно выглядит подобно “магическому заклинанию”, заставляя разра- 
ботчиков думать, что это нечто сложное, загадочное и непостижимое. На самом деле все 
не так. Это простая, реальная и действительно полезная вещь. Конечно, поначалу она 
может показаться непонятной, поэтому давайте рассмотрим несколько примеров. 

Предположим. что имеется класс РаззмогаВезеЕНе1рег, который должен отправ- 
лять электронную почту и производить запись в журнальный файл. Без 10С можно 
было бы позволить ему конструировать конкретные экземпляры МуЕма115епаег и 
МугодИг1 ег и применять их для непосредственного выполнения работы. Но в таком 
случае появились бы жестко закодированные зависимости Раззмог@ВезеЕНе1рег от 
других двух компонентов, с вплетением их специфических ответственностей и дизай- 
на АР-интерфейсов в РаззиогаВезеенНе]рег. После этого проектировать и тестировать 
РаззиогаВезетНе1рек в изоляции уже будет нельзя, а переход на другую технологию 
отправки почты или протоколирования потребует внесения существенных изменений 
в РаззиогаВезееНе1рег. Эти три класса окажутся спаянными вместе. И это — начало 
катастрофы под названием “спагетти-код”. 


7 Другим его распространенным названием является внедрение зависимости (4ерепдепсу 
ицесНоп — 01, который выглядит менее претенциозно; однако поскольку вариант ЮС при- 


меняется более широко, будем придерживаться именно его. 


74 часть |. Введение в АЗР. МЕТ МУС 


Шаблон ТоС помогает избежать описанных выше сложностей. Создайте некоторые 
интерфейсы, описывающие произвольные компоненты отправки электронной поч- 
ты и протоколирования (например, 1Епа115епдег и Т109\Иг1(ег), и затем сделайте 
РаззмогаКезееНе1рег зависимым только от этих интерфейсов: 


руБ11с с1азз РаззмогаВезеенНе1рек 

{ 
рг1уабе 1Ета115епдег ета115бепаег; 
рг1уасе ПюодМт1Еег Тодмг1еег; 


// Конструктор 
РУЮ11с РаззмогаВезеЕНе1рег (ТЕта11Зеп4ег ета115епек, ТЬодМг1фекг 1одМе1 ег) 
{ 
// Это код инверсии управления. Конструктор принимает экземпляры 
// ТЕта115еп4дег и ТТодМг1еег, которые сохраняются с целью 
// дальнейшего использования. 
+515. ета11бепдег = ема115еп4ег; 
+515. Тодмг1{фег = Тодмга ег; 
} 


// В остальной части кода используются _ета115епдегк и ЛодИк1еег 


} 


Теперь классу РаззиогаВезееНе1рег не нужно знать ничего ни о конкретном отпра- 
вителе почты, ни о средстве записи в файл журнала. Он работает только с интерфейса- 
ми, которые могут одинаково хорошо описывать любую технологию отправки почты и 
протоколирования, не вникая в детали каждого из них. Теперь легко переключиться на 
другую конкретную реализацию (например, для использования другой технологии) или 
поддерживать сразу несколько реализаций, не изменяя самого РаззмогОВезееНе]1рек. 
В модульных тестах, как будет показано ниже, можно просто копировать имитирован- 
ные реализации, которые позволяют выполнить простое тестирование, или же эмули- 
ровать определенные внешние условия (например, оптибочные). Слабая связность бла- 
гополучно достингута. 

Название инверсия управления проистекает из того факта, что внешний код (соз- 
дающий экземпляры РаззиогВезеене1рег) получает возможность управлять тем, ка- 
кие конкретные реализации зависимостей будут использоваться. Это противоположно 
нормальной ситуации, при которой сам РаззиогаВезеЕНе1рег управлял бы выбором 
конкретных классов, от которых он будет зависеть. 


На заметку! Объект РаззиогаВезе{Не1рег требует предоставления зависимостей через па- 
раметры конструктора. Это называется внедрением в конструктор. В качестве альтернативы 
можно было бы позволить внешнему коду передавать зависимости через общедоступные за- 
писываемые свойства; это называется внедрением в установщик. 


Пример, специфичный для МУС 


Давайте вернемся к примеру с аукционом и применим к нему концепцию 1оС. Нашей 
целью будет создание класса контроллера Ади пСопего11ек, который использует ос- 
нащенный ЫМО №ю ЗОЕ класс МепьехВероз1фогу, но без привязки Ади4пСопего11ег к 
МепрехгКероз16оку (со всеми его деталями ТЛМО 1ю ЭСЕ и строкой подключения к базе 
данных). 

Начнем с предположения, что вы заставили Мепфегкероз1еогу реализовать обще- 
доступный интерфейс: 
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руб11с 1пеегЕасе ТМепрехтзВероз1®огу 

{ 
уо1а дАаамепЬег (Мепфег пепег); 
Мепет ЕесспВуГосд1пМаше (5Ег1по 1091пМаме) ; 
%у01а ЗоБла1ЕСВапоез (); 

} 


(Разумеется, конкретный класс МепьегКероз1®оху, который теперь реализует 
этот интерфейс, по-прежнему существует} Теперь можно написать класс контроллера 
АЗРМЕТ МУС, зависящий от интерфейса ТцепьехВеро$1®огу: 


рую11с с1азз Аадт1пСопЕго]Лех : СопЕго1ег 
{ 


ТМепъегзВероз1$огу мепоегзВероз1$огу; 


// Конструктор 
рчЬ11с Ади1пСопеко1Тег (ТМепьегзКероз1охгу шепЬегзКероз1оту) 
{ 
{515 .мепЪегзВероз1Еоку = пепЬегзКеро$1оку; 
} 


ру611с Асе1опВези1Е Свапдетгод1пМаме (5&г1па о19Ъод1т, зЕг1па пемГод1п) 
{ 
Мепфег мепоег = мепъегзВероз1фогу.ЕеесрВуГод1оМапе (0о19Ъоа1п) ; 
петрег .Тод1пМаше = пемТод1п; 
пепоегзВероз1{огу. 5ирт1ЕСрапоаез (); 
// ... визуализировать некоторое представление 


} 


Ади пСопеко1Тег требует передачи тМепбегзВероз1®огку вкачестве параметра конст- 
руктора. Теперь Ади1пСопего!1ег может работать с интерфейсом ТтетрегзКероз1коху, 
и ему не нужно ничего знать о какой-то конкретной реализации. 

Это упрощает АдиапСопего1Текг во многих отношениях — во-первых, ему не нужно 
беспокоиться о строке соединения с базой данных (вспомните, что конкретный класс 
МепьегВероз1еоку требует передачи соппесЕ1оп5%г1па в качестве параметра конст- 
руктора). Самое болыпое преимущество состоит в том, что ТоС гарантирует кодирова- 
ние в соответствии с контрактом (с помощью явных интерфейсов}, при этом значитель- 
но повышается тестируемость (очень скоро мы создадим автоматизированный тест для 
Срапдегоч1тМаме ()). 

Но минуточку! Теперь в стеке вызовов необходимо создать экземпляр 
МепьекВероз1+огу и указать соппесЕ5%г1па. Так помогает ли на самом деле оС, или 
же просто переносит проблему с одного места в другое? Если есть масса компонентов и 
зависимостей, и даже цепочек зависимостей с дочерними зависимостями, то как управ- 
лять всем этим? Не получится ли конечный результат еще более сложным? На помощь 
приходит контейнер 10С. 


Использование контейнера инверсии управления 


Контейнер инверсии управления (оС) — это стандартный программный компонент, 
который поддерживает и упрощает инверсию управления. Он позволяет регистрировать 
наборы компонентов (например, абстрактные типы и выбранные конкретные реализа- 
пии) и затем поддерживает создание их экземпляров. Конфигурировать и регистрировать 
компоненты можно либо в файле ХМГ, либо в коде С# (или применить оба способа). 

Вызов во время выполнения метода вроде сопеа1пег.Везо1уе (Туре Фуре), где 
-у7се может быть определенным интерфейсом, абстрактным типом или определенным 
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конкретным типом, заставляет контейнер вернуть объект, удовлетворяющий определе- 
нию типа, согласно сконфигурированному конкретному типу. Качественный контейнер 
ТоС добавляет три дополнительных полезных средства. 


® Разрешение цепочки зависимостей. При запросе компонента, который сам имеет 
зависимости (например, параметры конструктора), контейнер рекурсивно удов- 
летворит эти зависимости. Это значит, что можно иметь компонент А, который 
зависит от В, тот, в свою очередь, зависит от С, и тд. Другими словами, можно 
просто думать о компонентах, а не об их связях, так как все связи установятся 
автоматически. 


® Управление временем жизни объекта. Если компонент А запрашивается более 
одного раза, должен ли каждый раз получаться один и тот же компонент А или же 
новый экземпляр? Контейнер обычно позволяет сконфигурировать “время жиз- 
ни” компонента, позволяя выбирать из предопределенных вариантов, включая 
зпоеюп (одиночка; каждый раз один и тот же экземпляр), бапзепЕ (изменяемый; 
каждый раз новый экземпляр), тзаплсе-рег-@геаа (экземпляр на поток), тзапсе- 
Гопта-ро4 (экземпляр из пула) и тд. 


® Конфигурация значений параметров конструктора. Например, если конструктор 
МепрегВероз1еогу требует строки по имени соппесЕ1оп5Ек1 па (как было ране*)}, 
то значение может быть указано в конфигурационном файле ХМЕ. Это грубая, но 
простая система конфигурирования, которая исключает любую потребность пере- 
давать в коде строки соединений, адреса ЗМТР-серверов и тп. 


Таким образом, в предыдущем примере понадобится сконфигурировать 
МепрегзВероз1®огу как активную конкретную реализацию ПШМепфегзВероз16оху. 
Затем, когда код вызовет сопеа1пег.Везо1 те (суреоЕ (Ади1пСопеко11ех)), контейнер 
определит, что для удовлетворения потребности конструктора АдитпСопЕго11ег в па- 
раметрах ему сначала понадобится реализация ПШМепоегзВероз1(огу. Он получит ее 
в соответствии со сконфигурированной конкретной реализацией (в данном случае — 
МепьегзВероз1®огу), применив сконфигурированную соппесЕ1оп5 Е к1па. Затем она 
будет использоваться для создания и возврага экземпляра Ади пСопеко11ек. 


Знакомство с Са5Не ИЛпабог 


СазИе УЛпазог (Виндзорский замок) — популярный контейнер 10оС с открытым ис- 
ходным кодом. Он поддерживает все эти средства и хорошо работает в сочетании с 
АЗР.МЕТ МУС. Поэтому когда вы применяете конфигурацию, которая отображает абст- 
рактные типы (интерфейсы) на определенные конкретные типы, и затем кто-то вызы- 
вает муй1пазокТпзсапсе .Везо1уе<Т5опеАЮзегкасЕТуре> (), он возвращает экземпляр 
соответствующего конкретного типа, сконфигурированного в данный момент, разрешая 
все цепочки зависимостей и соблюдая соответствие с настроенным стилем существова- 
ния компонентов. 

В рамках АЗРМЕТ МУС это особенно удобно для построения “фабрики контролле- 
ров”, которая может автоматически разрешать зависимости. Продолжая предыдущий 
пример, это значит, что зависимость АЗи1пСопего11ек от ТМепЬегзВероз1®огу будет 
разрешена автоматически, в соответствии с конкретной реализацией, сконфигуриро- 
ванной для ТМепрегзВероз1току. 


На заметку! Что такое “фабрика контроллеров”? В АЗРМЕТ МУС это объект, который вызывается 
для создания экземпляров того, что нужно контроллеру для обслуживания входящего запроса. 
„МЕТ МУС поддерживает встроенную фабрику по имени реРац1ЕСопЕхо11егЕаско{у, но 
ее можно заменить другой, по своему усмотрению. Для этого достаточно создать класс, реа- 
лизующий ТСопего11егРасеогу или подкласс Ре ап1 ЕСопего11етРаскоЁу. 
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В следующей главе СазИе УНпазог будет применяться для построения специальной 
фабрики контроллеров под названием И1п9зохСопЕго11екЕастоРу. Она позаботится 
об автоматическом разрешении всех зависимостей контроллера, когда это будет нужно 
для обслуживания запроса. 

АЗРМЕТ МУС предлагает простые средства для подключения специальной фаб- 
рики контроллеров; для этого понадобится лишь отредактировать обработчик 
Арр11саЕ1оп 5$аг® в файле С1оБа1.азах .сз, как показано ниже: 


ргосесфеа уо1а Арр11сае1оп_5фак (} 
{ 

Вед1тзеегВос®ез (КоитеТар1е.Воц®ез); 

СопЕхо1ТетВо11дег.Саггеп®. Зе СопЕго11ехЕасфогу (пех И1п9зогСопего1ЛегКасвогу()); 
} 


Пока достаточно знать, что это возможно. Полная реализация ИзпазогСопегоЛетЕас®огу 
рассматривается в следующей главе. 


Введение в автоматизированное тестирование 


В последние годы автоматизированное тестирование переместилось из зоны пери- 
ферийного внимания в основной поток, став первоочередной, совершенно необходи- 
мой методикой разработки. Платформа АЗРМЕТ МУС спроектирована так, чтобы мак- 
симально облегчить создание и выполнение модульных и интеграционных тестов. При 
создании нового проекта веб-приложения АЗРМЕТ МУС в среде У1з0а! Эва@ю предла- 
гается помощь в создании проекта модульного тестирования на основе шаблонов для 
нескольких каркасов тестирования (в зависимости от того, какие из них установлены). 

В мире .МЕТ можно выбирать из птирокого диапазона доступных каркасов модуль- 
ного тестирования, как коммерческих, так и с открытым кодом. Наиболее широко из- 
вестный из них — МОпН. Обычно в решении создается отдельный проект библиотеки 
классов, хранящий тестовые оснастки (если это еще не сделала автоматически сре- 
да \!1зна! Зба@ю). Тестовая оснастка (1е3{ Яхоте) представляет собой класс С#, опре- 
деляющий набор тестовых методов — по одному тестовому методу на поведение, ко- 
торое требуется проверить. Ниже приведен пример тестовой оснастки, написанной с 
применением МОпИ, которая проверят поведение метода Свапдероч1пМаме () класса 
АЗилпСопего ет из предыдущего примера: 


[ТезеЕ1хЕоге] 
риб11с с1азз АадилаСопего1Т1егТезез 
{ 
[ТезЕ] 
ру611с уо1А Сап Срапде_Тод1п_Мапе () 
{ 
// Подготовка (настройка сценария) 
Мепьек БоЬ = пеи МепБет { ТодлиаМаше = "Вор" }; 
ЕаКеМепюетзВероз1Когу героз = пем РГакеМепъетгзВероз1$огу(); 
тероз.Метрегз .Ада (Бо); 
Аадп1иСойпего]1ет сопёго11ет = пем Ади1иСоп®ко11ет (героз); 


// Действие (попытка выполнить операцию} 
сопЕго1Тет.СВапдетод1пМапе ("Воб", "Апазфаз1а"); 


// Утверждение (проверка результата) 
Аззеге.АгеЕаца1 ("Апазтазта", ЮоБ.Тод1пМапе); 
Аззеге.ТзТкце (героз .01а5$иби1ЕСВапоез); 


18 Часть !. Введение в АЗР.МЕТ МУС 


рг1уабе с1азз ЕакеМметрегзВероз1еоку : ТМепьегзВеро$1Фогу 
{ 
ру611с Г1зе<Мепег> Мепегз = пеи Т15Е<Мепрег> (); 
руб11с 6001 рР1а5ири1ЕСвапаез = Еа1зе; 
риуЮ11с уо1а АдамМепьег (Мепфегк шепьег) { 
ЕВгом пеи Мос пар1еперфедЕхсере1оп (); 
} 
рурю11с Мешек ГеесьВутод1пМапе (зе к1по 1од1пМапе) 
{ 
тебогп Мешрегз.Е1кзЕ (м => ш.Бод1пМате == 1о91пМапе) ; 
} 
руЮ11с уо1а зири1ЕСвапдез (} 
{ 
р1а5бобю1ЕСрапдез = 6кие; 


Совет. Код тестового метода Сап СБапде_Тод1п_Маше() следует шаблону, известному под на- 
званием подготовка/действие/утверждение (атапдае/асУаззей. — А/А/А). Подготовка означает 
настройку тестовых условий, действие — вызов тестируемой операции, а утверждение — про- 
верку результата. Соблюдение такой компоновки тестового кода облегчает его быстрое чтение, 
ивы наверняка оцените зто, когда придется иметь дело с сотнями тестов. Большинство тестов, 
приведенных в этой книге, соответствуют шаблону А/А/А. 


Эта тестовая оснастка использует специфичную фиктивную реализацию 
ТМепьегКероз16оку для эмуляции определенных условий (в репозитории имеется толь- 
ко один участник: ВоБ). Затем она вызывает тестируемый метод (СпапдеродМапе ()) и, 
наконец, проверяет резульгат теста, используя последовательности вызовов Аззег+ (). 
Запускать тесты можно в одной из многочисленных бесплатно доступных графических 
сред для тестирования®, например, МО СО (рис. 3.8). 

Графическая среда МО находит в сборке все классы [ТезЕЕ1хеиге] и все их ме- 
тоды [ТезЕ], позволяя запускать их либо индивидуально, либо все последовательно. 
Если все вызовы Аззеге (} проходят успешно, без генерации неожиданных исключе- 
ний, полоса будет иметь зеленый цвет В противном случае она будет красного цвета и 
выведется список утверждений, которые не прошли. 


Рис. 3.8. Графический интерфейс МИпЁ с помощью полосы зеленого 
цвета показывает успешное прохождение тестов 


8 При наличии сервера сборки (ге. при использовании непрерывной интеграции) эти тесты 
можете запускать с помощью инструмента командной строки в составе процесса сборки. 
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Может показаться, что для проверки такого простого поведения требуется слишком 
много кода, но для проверки даже очень сложного поведения понадобится не намного 
больше кода. Как будет показано в последующих примерах, с использованием инстру- 
мента имитации можно писать намного более лаконичные тесты, полностью исключая 
фиктивные тестовые классы вроде гакеМеперегзВеро$1®охгу. 


Модульные и интеграционные тесты 


Предыдущий тест является модульным (ирй &еэ, потому что тестирует один изоли- 
рованный компонент — АдиапСопеко11ег. Он не полагается на какую-либо реальную 
реализацию ТМепьегзВероз1оху, и не нуждается в доступе к какой-либо базе данных. 

Но все будет выглядеть совсем не так, если АЧи1пСопЕго11 ег не отсоединить от зави- 
симостей. Если он будет непосредственно ссылаться на конкретный МетьегВероз1огу, 
который, в свою очередь, содержит код доступа к базе данных, то протестировать 
АдиапСопего11ек не удастся — придется одновременно тестировать репозиторий, код 
доступа к данным и даже саму базу данных ЗОГ. Это не идеальный вариант по следую- 
щим причинам. 


® Медленное выполнение. При наличии сотен тестов придется терпеливо ждать, 
пока все они выполнят запросы к базе данных или веб-службам. 


® Риск получения ложных отрицательных результатов. Возможно, по каким-то 
причинам база данных была временно недоступна, но возникнет впечатление, что 
в коде присутствует нерегулярная оптибка. 


® Риск получения ложных положительных результатов. Два компонента могут 
случайно погасить ошибки друг друга. Бывает и такое! 


Когда вы намеренно соединяете в цепочку набор компонентов и тестируете их вме- 
сте, это называется интеграционным тестом. Эти тесты также важны, поскольку до- 
казывают правильность работы всего стека компонентов, включая отображения базы 
данных. Но по упомянутым выше причинам достичь лучигих результатов можно, если 
использовать в болыпинстве ситуаций модульные тесты, а несколько интеграционных 
тестов — только для проверки общего взаимодействия. 


Стиль разработки “красная полоса — зеленая полоса” 


Итак, вы получили начальные сведения об автоматизированном тестировании. Но 
как узнать, действительно ли ваши тесты что-то доказывают? Что если вы нечаянно 
пропустили важный вызов Аззех* () или не подготовили должным образом эмулируе- 
мые условия, из-за чего тест дал ложный положительный результат? Подход к разработ- 
ке “красная полоса — зеленая полоса” позволяет писать код, который неявно “тестирует 
сами тесты”. Ниже описана базовая последовательность действий. 


1. Вы принимаете решение о добавлении нового поведения в код. Еще до того, как 
приступить к реализации, напишете модульный тест для этого поведения. 


2. Удостоверьтесь, что тест не проходит (красная полоса). 
3. Реализуйте поведение. 
4. Удостоверьгесь, что тест проходит (зеленая полоса). 


5. Повторите действия 1-4. 


Тот факт, что резульгат прогона теста изменяет цвет полосы с красного на зеленый, 
даже если сам тест не изменялся, доказывает, что он реагирует на добавленное в код 
новое поведение. 
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Обратимся к примеру. Ранее в этой главе при рассмотрении примера с аукционом 
мы планировали создать в ГЕеп метод по имени Адав1а (), но пока еще не реализовали 
его. Давайте предположим, что требуемое поведение описывается следующим образом: 
допускается добавлять заявки на предмет торгов, но каждая следующая заявка должна 
иметь более высокую цену, чем все предыдущие. Для начала добавим в класс Тееп за- 
готовку метода: 


ручф11с уо1а АЗАВ1а (Мешбег ЕгопМешьег, дес1та1 51аАтоциф) 
{ 


ЕЬгои пем М№оЕГар1етепфедЕхсере1от (); 


На заметку! Писать заготовки методов перед написанием кода тестов не обязательно. Можно 
просто написать модульный тест, который пытается вызвать АЗаВза(), даже несмотря на 
то, что такой метод пока не существует. Очевидно, что это приведет к ошибке компиляции. 
Воспринимайте это как “проваленный тест”. Эту слегка упрощенную форму ТОВ вы увидите в 
действии в следующей главе. Однако ТОВ с заготовками методов поначалу может показаться 
более удобным подходом (именно его придерживаются в реальных проектах, если подобного 
рода ошибки компиляции вызывают раздражение). 


Может быть и очевидно, что этот код не удовлетворяет требованиям желаемого по- 
ведения. но это не помешает написать тест: 


[ТезЕЕ1хЕоге] 
рч611с с1азз Аисе1опТеетмТезе$ 
{ 
[ТезЕ] 
Рую11с уо1а Сап АЗа_В1а() 
{ 
// Подготовить сценарий 
Мепфег шепфег = пем МепЪег(); 
Тбем 16ет = пеи Тфем(); 


// Попытаться выполнить операцию 
1$еп.АдаВта (пепбет, 150); 


// Проверить результат 

Аззете.АгеЕсиа1 (1, 1%ет.В19$.Соцох {()); 
Аззеге.АгеЕдиа1 (150, 16ет.В1аз[0].В1ААточре); 
Аззеге.Акебапе (пепрег, 15ет.В1аз[0].Мепфег); 


} 


Запустите этот тест Конечно же, будет получена полоса красного цвета (сгенериру- 
ется исключение Мо Тир1епепеедЕхсерЕ1от). Самое время создать первую черновую 
реализацию АадвВ1а (): 


ру611с уо1а АЗаВла (Мепрек ЕготМетрет, деслта1т Б1аАтоппе) 
{ 
_Ю©1а5.Ааа(пем Вза 
{ 
Мепрег = ЕгопМепфег, 
В1ААпойпЕ = 61а9Амоппо, 
РасеРТасеа = Ра®еТ1те .Мои, 
Теештр = Е51$.тТЕеттр 
$); 
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Если вы теперь вновь запустите тест, то получите полосу зеленого цвета. Это дока- 
зывает возможность добавления заявок, но ничего не говорит о том, что цена новой 
заявки выше всех ранее поданных. Начните новый цикл “красная полоса — зеленая 
полоса”, добавив два новых теста: 


[ТезЕ] 

раБ11с хоза Сап Ааа Нлофек В1а() 

4 
// Подготовить сценарий 
Мепрег петЬет1 = пем Мепфек(); 
МепЬег пепоег? = пем Мепег(); 
ТЕеш 16еш = рем Тееп(); 


// Попытаться выполнить операцию 
16ем.Ааавз АЯ (шепЪех1, 150); 
16ем.Ааавз а (шенетх2, 200); 


// Проверить результат 

Аззеге.АгеЕаоа1 (2, Цепт.В19$.Сочок ()); 
Аззеге.АгеЕаоа1 (150, 16еп.В19$[0].ВлаАтонпЕ); 
Аззеге.АгеЕдиа1 (200, 16ет.В19$[1].В19АтопоХ); 
Аззеге.Агебапе (шепрет1, 16ет.В19$ [0] .Мепфег); 
Аззеге.Агебапе (шепьег2?, 16ет.В19$ [1] .Мепег} ; 


} 


[ТезЕ] 
рУр11с уо1А СаппоЕ АЧЯ Томег В19() 
{ 
// Подготовить сценарий 
МепЬег шепрег1 = пем Мепрехг(); 
Мепьет пепоехг? = пеи Мепрег(); 
ТЕет 16епш = рем Тбсеп(); 


// Понытаться выполнить операцию 
1Еем.Ааавта (щепьетх1, 150); 
гу 
{ 
16ем.Ааавза (тепфетх2, 100); 
Аззеге.Еа11 ("5Вои1Я ЕВгои ехсерЕ1оп веп 1пуа11а Ь1а аффепруеей"); 
// неверная заявка 


} 
саёсв (Тпуа119Орегае1опЕхсерЕ1оп) { /* Ожидается */ } 


// Проверить результат 

Аззеге.Агеаоа1 (1, 16ет.В195.Совие ()); 
АззегЕ.АгеЕаиа1 (150, 16ет.В19$[0].В1аАтониЕ); 
Аззеге.Агебаше (шепфег1, 16еп.В19$[0].Мепьег}; 


} 


Запустив все три теста вместе, вы увидите, что Сап_ даа в1аи Сап_ Ааа Нлапег В1а 
пройдут успешно, а СаппоЕ АЗЯ Гомекг_В193 даст сбой, доказывая, что тест корректно 
обнаруживает несоблюдение правила о возрастающих ценах в заявках (рис. 3.9). 

Разумеется, ведь пока еще нет никакого кода, который бы предотвращал добавление 
заявок с меньшей ценой. Обновите метод Тфеп.Адав1а () следующим образом: 
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› ТЕИдауеь 3 Тез Вы: 2 Ройние 1 мтогеы 5 берез Яыг Тат: 


Рис. 3.9. Графический интерфейс МУпй показывает, что код 
не предотвращает добавление заявок с более низкой ценой 


рою11с уота Ааав1а (Мепьег ЁЕгопМепег, Яес1та1 Ь19Аточре) 
{ 
1= ((В195.Сопое() > 0) && (ЪЗ1ЯАтоцпе <= В193 .Мах(Ъ => Ь.В1ЧАмоцпе))) 
ЕВгои пем Тпуа1190регае1опЕхсерЕ1 оп ("В1@ фоо 1ом"); 


// цена заявки ниже предыдущих 
е1зе 


{ 
_Ю1а5.АЧА (пем В1а 


{ 
Мепрег = ЕгоиМепфег, 
В1аАтоцпЕ = Б1аАпоцпе, 
РабеР1асеЯ = БабеТ1ме.Мом, 
ТеештТр = 65153 .тЕептр 

}); 


} 


Снова запустив тесты, вы увидите, что все три пройдут успешно! В этом и состоит 
суть разработки “красная полоса — зеленая полоса”. Тесты должны что-то доказывать, 
потому что их резульгат изменяется после реализации соответствующего поведения. 
Развивая данный пример, определите также поведения для ошибочных ситуаций (на- 
пример, когда Мепрег равен по11 или значение ю1ЗАпоип® является отрицательным), 
напишите для них тесты и затем реализуйте соответствующие поведения. 


Стоит ли игра свеч 


Написание тестов определенно означает увеличение объема кодирования, но зато 
тарантирует, что поведение кода теперь “заперто” навсегда — никто не сможет нару- 
птить его незаметно, а вы можете выполнить его рефакторинг, после чего быстро удо- 
стовериться, что вся кодовая база по-прежнему работает правильно. Работать над мо- 
делью предметной области, контроллерами и служебными классами, попутно тестируя 
поведение, даже без необходимости запуска веб-браузера, очень удобно. К тому же, это 
быстрее, плюс можно протестировать граничные условия, которые было бы очень труд- 
но эмулировать вручную через графический интерфейс приложения. Может ноказать- 
ся, что добавление итеративной разработки в стиле “красная полоса — зеленая полоса” 
прибавляет работы, но так ли это? Если все равно нужно писать тесты, почему бы ни 
написать их вначале? 

Разработка в стиле “красная полоса — зеленая полоса” представляет собой основную 
идею, лежащую в основе разработки, управляемой тестами (е${-апуеп аеу@юртепе — 
ТОО). Сторонники ТОО используют цикл “красная полоса — зеленая полоса” для каж- 
дого изменения, проводимого в программном обеспечении, и когда все тесты успешно 
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проходят, выполняют рефакторинг кода для повышения его качества. В конечном итоге 
набор тестов должен полностью определять и документировать поведение всего прило- 
жения, хотя обычно допускается, что некоторые программные компоненты, в частно- 
сти, представления и код клиентской стороны, при веб-разработке не всегда могут быть 
протестированы подобным образом. 

Платформа АЗРМЕТ МУС специально спроектирована для обеспечения максималь- 
ной тестируемости. Классы Сопего11ех не привязаны к исполняющей среде НТТР —они 
обращаются к Вестезь. Везропзе и прочим объектам контекста только через абстракт- 
ные интерфейсы, так что на время тестирования их всегда можно заменить фиктивны- 
ми или имитированными версиями. Создание экземпляров контроллеров через контей- 
нер 10С позволяет их привязать к любому графу слабо связанных компонентов. 


Новые языковые средства С# 3.0 


В заверитающих разделах зтой главы вы узнаете о новых средствах, которые появи- 
лись в С# вместе с выходом МЕТ 3.5 и \1зца1 Зла 2008. Если вам уже известно все о 
МО, анонимных типах, лямбда-методах и тп., то можете спокойно пропустить остаток 
материала и перейти к следующей главе. Эти знания понадобятся, чтобы по-настояще- 
му понять, что происходит в приложении АЗР.МЕТ МУС. При изложении дальнейшего 
материала предполагается. что вы знаете С# 2.0, включая обобщения, итераторы (на- 
пример, оператор у1е1А гесагп) и анонимные делегаты. 


Проектная цель — язык интегрированных запросов 


Почти все новые средства языка С# 3.0 объединяет нечто общее: все они предна- 
значены для поддержки языка интегрированных запросов (Гапбиаве Ниергаеа Оиегу — 
№0). Идея ММО состоит в том, чтобы превратить запросы данных в естественное сред- 
ство языка. В резульгате выбор, сортировка, фильграция или трансформация наборов 
данных — будь то набор объектов МЕТ в памяти, набор узлов ХМЕ, в дисковом файле 
или набор строк в базе данных $01, — осуществляется согласно стандартному, под- 
держиваемому НиеШЗепзе синтаксису в коде С# (при этом еще и сокращается объем 
кодирования). 

Рассмотрим очень простой пример на С# 2.0. Для нахождения трех самых болыших 
целых чисел в массиве необходимо написать приблизительно такую функцию: 


106[] бееТортТЬтееуУа1аез (106[] уа1щез}) 
{ 
Аггау. боге (уа1щез); 
106[] сорТЬгее = пеи 106[3]; 
Бок (1401=0;1< 3; 1++) 
ЕорТЬкее [1] = уа]1щез [уа]иез.ТепаеВ - 1-1]; 
тебигп ЕорТЬгее; 


} 
Ту же задачу можно решить с использованием 11М№О: 
уаг ЕорТЬгее = (Егош 1 1п уа]фаез огдетфу 1 дезсер@1та зе1есь 1) .Таке (3); 


Обратите внимание, что код С# имеет неприятный побочный эффект —он нарушает 
исходный порядок сортировки массива, и нужно приложить дополнительные усилия, 
чтобы избежать этого. Коду ММО упомянутая проблема не присуща. 

Поначалу разобраться, как работает этот странный ЗОГ.-подобный синтаксис, нелег- 
ко. А ведь более сложные запросы 1ЛМ@ могут еще и соединять, группировать и фильт- 
ровать гетерогенные источники данных. Давайте рассмотрим но очереди каждый из 
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лежащих в его основе механизмов, и не только, чтобы помочь понять ММО, но также 
потому, что эти механизмы являются полезными инструментами программирования 
сами по себе. Чтобы эффективно применять АЗРМЕТ МУС, необходимо хоропто пони- 
мать их синтаксис. 


Расширяющие методы 


Приходилось ли вам сталкиваться с ситуацией, когда требуется добавить допол- 
нительный метод в класс, разработанный не вами? Расширяющие методы позволяют 
“внедрять” методы в произвольный класс, даже если тот объявлен как зеаТеа (те. гер- 
метизирован), не открывая доступа к приватным членам и не наруптая инкапсуляции 
никаким иным образом. 

Например, стандартный класс зЕг1пд не имеет метода для преобразования строки 
в регистр “начинать с прописных” (те. первая буква каждого слова строки должна быть 
заглавной). Для решения этой задачи можно определить статический метод: 


рую11с збаЁ1с зЕг1па ТоТ1Е1еСазе (зЕх1па эт) 
{ 
ЧЕ Ее 
хесагп по11; 
е15е 
тебогп Со1ЕогеТпЕо .СикгерОТСи16оте .ТехеТоЕо.ТоТ1Е1еСазе (36г); 
} 


Поместив этот статический метод в общедоступный статический класс, и указав 
ключевое слово ©5153 в списке параметров, можно создать расширяющий метод (те. 
статический метод, принимающий параметр (115), как показано ниже: 


руБ11с зфаЁ1с с1азз МуЕхеепз1оп5 
{ 
руь11с зеаф1с зЕгапо Тот1Е1еСазе (+115 5Ег1па 5%) 
{ 
ТЕ (3з6х == 0011) 
тесиакп по11; 
е1зе 
тебагр Сао огетпЕо .СиккепеОТСо1еоте .ТехЕТоЕо.ТоТ11еСазе (3ег); 


} 


Компилятор С# позволяет вызывать этот метод, как если бы он принадлежал тину 
„МЕТ, соответствующему параметру (01$. Например: 


5Ет1па р1асе = "зоо В мезЕ аизЕгка11а"; 
Сопзо1е.Икг1 Ее 1 пе (р1асе .ТотТ1(1еСазе ()}; // Печатает "босЕБ Мезф Аизега11а“ 


Конечно, все зто полностью поддерживается средством НиеШЗепзе. Обратите вни- 
мание, что на самом деле новый метод в класс зе г1па не добавляется. Это просто 
синтаксическое удобство: компилятор С# в действительности преобразует код к нечто 
такое, что выглядит в точности. как первый нерасптиряющий статический метод в пре- 
дыдущем коде, так что зто никоим образом не нарушает защиты доступа к членам или 
правила инкапсуляции. 

Ничто не мешает определить расширяющий метод на интерфейсе, что создает ра- 
нее невозможную иллюзию, что весь код автоматически разделяет все типы, реали- 
зующие интерфейс. В следующем примере для получения всех четных значений из 
ТЕпомегаю1е<10+> используется оператор С# 2.0 у1е1а гебогп: 
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рур11с зкаЕ1с с]1аз5 МуЕхсепз1оп5 
{ 


ру611с эЕаЁ1с ТЕпомегаю1е<1пе> ИНегеЕуеп (%Ь13 ТЕПомега61е<1пЕ> уа1иез) 


{ 


ЕогеасВ (10 1 1п уа1аез) 
ТЕ (1%2== 0) 
у1е1а гебиги 1; 


} 


Теперь метод УТегеЕуеп () будет доступен в Г156<10Е>, Со11есетоп<1пе>, 10%[] и 
во всем, что реализует ТЕпомегаь1е<1пЕ>. 


Лямбда-методы 


Если необходимо обобщить приведенную выше функцию МпехеЕуеп (} в произволь- 
ную функцию УЪеге<Т> (), которая выполняет произвольную фильтрацию произволь- 
ного типа данных, можно использовать делегат, как показано ниже: 


рую11с эбаЕ1с сфазз Мухеепз1опз 
{ 
рур11с Яе1едаее 6оо1 Ст1Кегла<Т>(Т уа1ое); 
рию11с зваЕ1с ТЕпомегар1е<Т> Ипеге<Т> (513 ТЕпошегаЪ1е<Т> уа]ез, 
Ст1еег1а<Т> сг1еегфа) 
{ 
ЕогеасВ (Т 1%ет 1п уа1пез) 
ТЕ (схлеегЛа (16еш)) 
у1е1а гебоги 16еп; 


} 


После этого появляется возможность, например, использовать Ипеге<Т> для получе- 
ния всех строк в массиве, которые начинаются с определенной буквы, передавая ано- 
нимный делегат С# 2.0 в качестве параметра сг1Еегза: 


32г109[] пащез = пем $6:1049[] { "В111", "даре", "Вор", "ЕгкапК" }; 
ТЕротегаю1е<5Ег1п9> Вз = пашез .ИМеге<$(т1поа> ( 
Че1едафе (5Ет1па 5) {[ гебигп $.беакЕзи1ен ("в"); } 
); 


Согласитесь, что это выглядит несколько неуклюже. Именно поэтому в С# 3.0 появи- 
лись лямбда-методы (позаимствованные из языков функционального программирова- 
ния), которые представляют собой упрощенный синтаксис записи анонимных делега- 
тов. Предыдущий код теперь можно сократить следующим образом: 


$Е1109[] пащез = пем з6:409[] { "В111", "дапе", "Вор", "Екапк" }; 
ТЕпапега©1е<5+тх11п9> В5 = пащез .Меге<$%х1п9> (5 => з.б$акезМа ЕН ("В")); 


Это выглядит намного аккуратнее, и даже читается почти как предложение на анг- 
лийском языке. В общем случае, лямбда-методы позволяют выразить делегат с любым 
количеством параметров; для этого применяется следующий синтаксис: 


(а, Ь, с) => бопегирсЕ1опОЕ(а, Ъ, с} 


При описании делегата, который принимает только один параметр, первую нару 
скобок можете опустить: 


х => бопеРопсЕ1опоЕ (х) 
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В лямбда-метод можете поместить более одной строки кода, завершив их операто- 
ром гебагп: 
х => { 
уаг гези1е = ЗомегапсЕЗопоЕ (х); 
тебогп гези1е; 


} 


Помните, что это всего лиить средство компилятора. Лямбда-методы можно исполь- 
зовать при обращении к сборке .МЕТ 2.0, которая ожидает делегатов. 


Выведение обобщенного типа 


На самом деле, предыдущий пример можно дополнительно упростить: 


зЕглиа[] пашез = пем з6тлоа[] { "В111", "Заре", "Во", "ЕгапК" }; 
тЕПИМегаЪ1е<зЕг4па> Вз = патез .МНеге ($ => $.ЗакЕзИз ЕВ ("В")); 


Обратите внимание на отличия. На зтот раз мы не снецифицируем параметр обоб- 
щения для Ивеге<т> () , а просто нишем ИЪеге (). Это еще один из трюков компилятора. 
С# 3.0: он может самостоятельно вывести тип аргумента обобщенной функции из пе- 
реданного ей типа возврата делегата (или лямбда-метода). (В компиляторе С# 2.0 уже 
присутствовали некоторые возможности выведения обобщенного типа. но ранее такого 
он делать не мог.) 

Теперь у нас есть операция Ицеге () совершенно общего назначения с аккуратным 
синтаксисом, что в значительной мере продвигает вперед к пониманию работы ММО. 


Автоматические свойства 


На первый взгляд, автоматические свойства выглядят как странное отклонение от 
темы обсуждения, но это не так. Болыпинство программистов С# до сих пор порядочно 
утомляла задача написания свойств вроде показанных ниже: 


ргутаее зех1па _папе; 


рур11с $зЕг1пд Мате 

{ 
дее { хебогп папе; } 
зеЕ { паше = уа1ае; } 


} 
ре1уафе 110 аде; 


руЬ11с 116 Аде 
{ 
деЕ { гебогп _аде; } 
зеё { _аде = уа1ще; } 
} 
ить 


При таком объеме кода так мало толку. При этом возникает искушение открыть 
подобным образом все поля класса, которые должны быть общедоступными. Однако 
при таком подходе в будущем не удастся добавить логику средств установки и извле- 
чения, не нарушив совместимости со сборками, которые уже поставлены заказчикам 
(и затрудняя привязку данных). К счастью, компилятор С# 3.0 теперь распознает новый 
синтаксис: 


ру611с зЕхг1па Маше { деё; зес; } 
рую11с 116 Аде { деё; зеф; } 
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Это так называемые автоматические свойства. Во время компиляции компилятор 
СЯ 3.0 автоматически добавляет скрытое поле для каждого автоматического свойства 
(с именем. к которому никогда не будет обращения напрямую) и привязывает к нему 
очевидные средства установки и извлечения. Таким образом, кодировать все вручную 
не приходится. Однако обратите внимание, что опускать конструкции дее; или зе%;, 
создавая поля, доступные только для чтения или только для записи, нельзя; вместо это- 
го необходимо указывать модификаторы доступа. Например: 


ру611с зЕг1па Маше { дес; рг1уабе зек; } 
рир11с 116 Аде { 1пегра1 деЕ; зе®; } 


Если в будущем потребуется добавить специальную логику установки и извлечения, 
автоматически свойства можно превратить в обычные, не нарушая совместимости. 
Правда, с зтим средством связано одно ограничение: автоматическому свойству нель- 
зя присваивать значение по умолчанию, как это делается с полем (например, рг1уафе 
оЮ)есе шмуОЮ]есЕ = пеи оБЗесь();), поэтому они должны инициализироваться (если 
это необходимо) в конструкторе. 


Инициализаторы объектов и коллекций 


Рассмотрим еще одну распространенную задачу программирования, которая также 
довольно утомительна: конструирование объектов с последующим присваиванием зна- 
чений их свойствам. Например: 


Регзоп регзоп = пеи Регзоп (); 
регзоп.Маше = "5ееуе"; 
регзоп.Аде = 93; 
Вед1зЕекРегзоп (регзоп); 


Эта простая задача потребовала для своей реализации четырех строк кода. В компи- 
ляторе С# 3.0 поддерживается новый синтаксис: 


Вед1зЕекРегзоп (пем Регзоп { Маше = "Зсеуе", Асде = 93 }); 


Он выглядит намного лучше. С помощью нотации с фигурными скобками после пех 
можно присваивать значения доступным для записи свойствам нового объекта, что 
очень удобно, когда необходимо быстро создать новый экземпляр для передачи мето- 
ду. Код в фигурных скобках называется инициализатором объекта, и при необходи- 
мости его можно помещать после обычного набора параметров конструктора. В случае 
если вызывается конструктор без параметров, нормальные скобки конструктора можно 
опустить. 

Компилятор С# 3.0 также поддерживает аналогичный способ инициализации кол- 
лекций. Например, код 


1136Е<56г10а9> соипег1ез = пем Та зЕ<8Ег1та>(); 
соипЕт1ез.Ада ("Епо1апа"); 

соипЕтг1е$.АаЧа ("Тге1апа") ; 

соипЕг1е$.Ада ("$соф1апа") ; 

соипЕгТез.АЗа ("Иа1ез"); 


теперь можно сократить следующим образом: 


11$56<86:1п9> сопоех1ез = пем Г15Е<$6т1поа> { 
"Епо1ар@", "Тге1арЯ", "5соЕ1арЯ", "Ма1ез" 
}; 


Компилятор позволяет использовать зтот синтаксис при конструировании любого 
типа, предоставляющего метод по имени Ааа (). Предусмотрен также соответствующий 
синтаксис для инициализации словарей: 
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РасЕтопагу<10е, зек1па> 21рСбоаез = пеи Русе1опаку<1пе, зег1па> { 
{ 90210, "Веуек1у Н1115" }, 
{ 73301, "АчзЕли, ТХ" } 


Выведение типа 


В С# 3.0 также появилось новое ключевое слово уаг, посредством котором можно 
определять локальную переменную без указания явного типа — компилятор выведет его 
на основе присваиваемого значения. Ниже показан пример: 


уаг пом = пеи РафеТаше (2001, 1, 1); // Переменная получает тип РафеТ1те 
102 ЧауОЕУеаг = пои.РауОЕУеаг; // Это допустимо 
зЕх1оа СезЕ = пои. боюзЕг1р9 (1, 3); // Ошибка компиляции! 


// Такой функции Басет1ше нет! 


Это называется выведением типа (буре пегепсе) или неявной типизацией. Обратите 
внимание, что вопреки оптибочному предположению, которое поначалу приходит в го- 
лову многим разработчикам, речь не идет о динамически типизированной перемен: 
ной (в том смысле, как все переменные динамически типизированы в ЗауаЗсирь, или в 
смысле понятия динамического вызова в С# 4.0). После компиляции такая переменная 
будет явно типизированной, как и раныше; единственное отличие состоит в том, что 
тип, который должна иметь переменная, определяется компилятором, а не явно ука- 
зывается разработчиком. Неявно типизированные переменные мотут использоваться 
только в контексте локального метода: применять уаг с членами класса или в качестве 
типа возврата нельзя. 


Анонимные типы 


Интересно, что за счет комбинирования инициализаторов объектов с выведением 
типа простые объекты для хранения данных можно конструировать, вообще не опреде- 
ляя соответствующего класса. Например: 


уахг за1езБафа = пеи { Рау = пем РафеТае (2009, 01, 03), ро11ахУа1ме = 353000 }; 
Сопзо1е.Итасет1 те ("Тр {0}, ме зо1а {1:с}", за1езБаба.Бау, за1езРаба.0о11ахУа1е); 


Здесь за1езРаба — объект анонимного типа. И снова, зто не значит, что он типи- 
зирован динамически: на самом деле это некоторый реальный тип „МЕТ, имя которого 
вы не можете узнать (или повлиять на него). Компилятор С# 3.0 генерирует невиди- 
мое определение класса прямо во время компиляции. Обратите внимание, что средство 
БиеШ$епзе в \У!зна1 За 1ю полностью осведомлено о происходящем, и когда вы наберете 
за1езрака., оно предложит соответствующий список свойств, даже несмотря на то. что 
этот тип покамест не существует Действительно замечательное средство. 

Для каждой комбинации имен свойств и типов, которые используются для построе- 
ния объектов анонимных типов, компилятор генерирует разные определения классов. 
Таким образом, если два объекта анонимного типа имеют одинаковые имена и типы 
свойств, то во время выполнения они будут отнесены к одному и тому же типу „МЕТ. 
Это означает что объекты согласованных анонимных типов могут быть помещены в 
анонимный массив, например: 


уаг Яа1]уба1ез = пем[] { 
рем { Рау = пем РабеТ1те (2009, 01, 03), Ро11акУа1ае = 353000 }, 
геи { Рау = пеи Бабет1ше (2009, 01, 04), Ро11атУа1ае 379250 }, 
реи { Рау = пем БакеТаме (2009, 01, 05), Ро11акУа1ме 388200 } 


И 
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Чтобы такое стало возможным, все анонимно типизированные объекты в массиве 
должны иметь одну и ту же комбинацию имен и типов свойств. Обратите внимание, 
что переменная За11у5а1ез объявлена с помощью ключевого слова таг, а не уаг[], 
Т1зЕ<уаг> или тому подобного. Поскольку уаг означает “все, что подходит”, оно явля- 
ется самодостаточным и обеспечивает полную безопасность типов как во время компи- 
ляции, так и во время выполнения. 


Собираем все вместе 


Если вы никогда ранее не сталкивались ни с одним из перечисленных средств, 
то, возможно, вы не внолне понимаете, как все это укладывается в концепцию ММО. 
Давайте сведем все воедино. 

Вы уже видели. как можно реализовать операцию М№еге () с помощью расширяю- 
щих методов и выведения обобщенного типа. Следующий шаг состоит в том, чтобы 
разобраться, каким образом явно типизированные переменные и анонимные типы 
поддерживают операцию проекции (те. эквивалент части ЗЕТЕСТ запроса ОВ). Идея, 
лежащая в основе проекции, заключается в том, что для каждого элемента в исходном 
наборе необходимо выполнить отображение на трансформированный элемент, который 
попадет в целевой набор. В терминах С# 2.0 для отображения каждого злемента нужно 
было бы применить обобщенный делегат как показано ниже: 


руь11с ае1едаее Трез® ТгтапзЕогтаЕлоп<Т$гс, ТОезЕ> (Т5гс 16еп); 


Однако в С# 3.0 можно использовать встроенный тип делегата Гопс<Т$кс, ТБез®>, 
который полностью зквивалентен. Таким образом, получаем операцию проекции обще- 
го назначения: 


рар11с зтаЕ1с с1аз5 МуЕхеепз1о01п5$ 
{ 
руЬ11с збаЕ1с ТЕпомега 1е<ТрезЕ> бефесе<Т, ТОез®> (51$ ТЕпимегаю1Те<Т> уа1щез, 
Рирс<Т, ТОезЕ> ЕгапзЕогта1оп) 


ЕогеасВ (Т 1сет 1п уа1оез) 
у1е1а гебогп ЕгапзЕогиа Топ (16 ет); 


} 


Теперь, учитывая, что и 5е1есе<Т, ТОез®>(). и ИБеге<Т> () доступны для любого 
ТЕпонегаю1е<Т>, можно выполнять произвольную фильтрацию и отображение данных 
на анонимно типизованную коллекцию: 


// Подготовить данные для примера 
з6г1п9[] папебаба = пеи $Ех109[] { "56еуе", "У1ищу", "Се11пе", "Агро" }; 
// Трансформировать в перечислимые анонимно типизированные объекты 
уаг реор1е = пашерака.ИБеге (з6х => з6г != "91щу") // Отфильтровать по У1ишу 
.Зе1ес® (зЕх => пем { // Проектировать на анонимный тип 
Маше = $%г, 
ТебсбегзТоМаше = зЕг.ШердеЕВ, 
НазТопаМаше = (36г.ТепаеН > 5) 
р; 
// Извлечь данные из перечисления 
Еогеасй (уаг регзоп 1п реор1е} 
Сопзо1е.ИМх1 сете ("{0} Баз {1} 1ебсегз 10 &Ве1г паме. {2}", 
регзоп .Мапте, 
регзоп.Геефегз ТпМапе, 
регзоп.НазГопа9Маше ? "ТВаф'з Лора!" ; "" 
); 
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В результате на консоль выводятся следующие строки: 


Зсеуе Баз 5 1еёегз 1п ЕБе1г папе. 
Се11ре Ваз 6 1еёЕег$ 1п ЕВе1т паше. ТВаб'$ 1опод! 
Агпо Баз 4 1еббегз 1п ЕБелг папе. 


Обратите внимание, что мы присваиваем результаты запроса неявно типизиро- 
ванной (уаг) переменной. Это потому, что реальным типом является перечисление из 
анонимно типизированных объектов, так что явно записать ее тип невозможно (хотя 
компилятор может это сделать во время компиляции). 

Теперь вам должно быть ясно, что, имея бе1есь() и Ицеге (). можно построить 
основу языка объектных запросов общего назначения. Вне всяких сомнений, можно 
реализовать также и ОгаегВу (), Фо34п(), СкоирВу() и тд. Но, конечно же, делать это 
не понадобится, потому что в вашем распоряжении есть язык ММО 0 Оес{5 — язык 
запросов общего назначения для находящихся в памяти коллекций объектов МЕТ, ко- 
торый построен в точности так, как было описано выше. 


Отложенное выполнение 


Прежде чем двигаться далыце, следует сделать одно финальное замечание. Поскольку 
весь код, использованный для построения этих операций запроса, использует блоки 
итератора С# 2.0 (те. оператор у1е1а кебогп). перечисления на самом деле не обра- 
батываются до тех пор, нока из них не будут выбираться элементы. То есть, когда вы 
создаете экземнляр переменной уаг реор1е в предыдущем примере, это определяет 
природу и параметры запроса (напоминает замыкание"), но на самом деле не касается 
источника данных (паперафа) до тех пор, пока последующий цикл ЕогеасВ не начнет 
извлекать результаты один за другим. И даже тогда код итератора выполняется по од- 
ной итерации за раз, каждую запись трансформируется, только когда она будет специ- 
ально запрошена. 

Это нечто болышее, чем просто теоретический момент. Знание того, что дорогостоя- 
щая операция не будет выполняться до самого последнего возможного момента, имеет 
огромное значение, особенно при составлении и комбинировании запросов к внешней 
базе данных ЗОГ. 


Использование ЦМО {10 ОЦщес5 


Итак. мы. наконец, добрались до этого момента. Ранее уже было показано, как рабо- 
тает ИМО №0 Оес{з. При желании, с использованием новых средств С# 3.0 его можно 
полностью переделать под собственные нужды, добавив, например, дополнительные 
операции запросов общего назначения. 

Когда разработчики ММО в М!сгозой дошли до этого этапа, они провели некоторое 
тестирование удобства и решили, что работа завершена. Как и можно было ожидать, 
конечный результат первых пользователей не устроил. Посынались нарекания на че- 
ресчур сложный синтаксис, и вопросы, почему он настолько не похож на язык ЗОТ? Все 
зти скобки и точки вызывали у людей головную боль. Поэтому разработчики ЫМО вер- 
нулись к работе и спроектировали более выразительный синтаксис для тех же запросов. 
Теперь предыдущий пример можно было выразить так: 


уаг реор1е = ЁЕкош з©г 1п папераба 
зреге зёк != "У1иму" 


ЗВ языках функционального программирования замыкание (с1озите) позволяет отложить 
выполнение блока кода, не теряя никаких переменных в его контексте. В зависимости от 
точного определения термина анонимные методы С# можно или нельзя трактовать как на- 
стоящие замыкания. 
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зетесЕ пем 
{ 
Маше = зёг, 
ТессегзТиМаме = зсг.Бепоеи, 
НазГопоМате = (зёк.Тепраёев > 5) 
}; 


Этот новый синтаксис называется выражением запроса (даегу ехргезз1юоп). Он яв- 
ляется альтернативной написанию цепочек расширяющих методов ММО — до тех пор, 
пока запрос следует предопределенной структуре. Согласитесь, он очень напоминает 
ЭСТ, за исключением того, что зе1ес® находится в конце, а не в начале выражения 
(что имеет больше смысла, если хорошо подумать). 

Хоть в данном примере это не особенно заметно, но выражения запросов сущест- 
венно легче читать, чем цепочки расширяющих методов, особенно в случае длинных 
запросов с множеством конструкций и подконструкций. Выбор синтаксиса для приме- 
нения — дело ваше; во время выполнения между ними нет никакой разницы, учитывая, 
что компилятор С# 3.0 все равно на раннем этапе компиляции преобразует выражения 
запросов в цепочки вызовов расширяющих методов. Некоторые запросы легче выра- 
зить цепочкой вызовов функций, а другие лучше выглядят в виде выражений запросов. 
Пробуйте постоянно переключаться между этими двумя синтаксисами. 


На заметку! В синтаксисе выражений запросов ключевые слова (Егом, итеге, огаекъу, 
зе1есе итп.) являются жестко закодированными. Возможность добавления собственных клю- 
чевых слов отсутствует. Множество расширяющих методов ЧМО доступно только через прямой 
их вызов: они не имеют соответствующего ключевого слова в синтаксисе выражений запросов. 
Разумеется, вызовы расширяющих методов можно использовать и внутри выражения запроса 
(например, Еком р 11 реор1е.Р1зЕ1псе() окаегфу р.Маме зе1есЕ р). 


Лямбда-выражения 


Последнее новое средство компилятора С# 3.0, не часто применяемое в код, от- 
крывает новые возможности для проектировщиков АРЕ-интерфейсов. Это основа как 
для ГЛМО Юг Ехегу 15, так и для ряда потрясающе выразительных АР-интерфейсов 
АЗРМЕТ МУС. 

Лямбда-выражения выглядят похожими на лямбда-методы — их синтаксис иденти- 
чен, но во время компиляции они не преобразуются в анонимные делегаты. Вместо это- 
го они встраиваются в сборку не в виде кода, а в виде данных, называемых абстракт- 
ным синтаксическим деревом (аЪБзёгас® эутцах гее — АЗТ). Ниже показан пример: 


// Это обычный лямбда-метод, компилируемый в код „МЕТ 
Рирс<1пе, 116, 116> а94а1 = (х, у) => х +у; 


// Это лямбда-выражение, компилируемое в *данные* (АЗТ) 
Ехргеззлоп<Еапс<1лпе, апф, 106>> а@42 = (х, у) => х+у; 


// Выражение можно скомпилировать *во время выполнения*, после чего запустить 
Сопзо1е .Иг1фе11пе ("1 +2 = " + а992.Сошр11е () (1, 2)); 


// Во время выполнения его можно просматривать как иерархию выражений 
Сопзо1е.ИглееГ1пе ("Воо® по4е суре: " + а992.Воду.МодеТуре .То5Ег1п9 ()); 
В1пагуЕхргезз1оп гооЕМоде = а992.Воду аз В1пакуЕхргезз1оп; 

Сопзо1е .Иг1фе|1пе ("1Н5: " + гооМоде .ЦеЕе.МодеТуре .То5ег1па()); 
Сопзо1е.Ит1ее!1 пе ("ВН5: " + кооЕМоде .вВ1оре.МодеТуре.То5Ет1по ()); 
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Этот код даст следующий вывод: 
1+2 =3 

ВооЕ поде туре: Ада 

ТН$: Рагапефег 

ВН5: Рагкамебек 


Таким образом. просто заключая тип делегата в Ехргезз1оп<>. можно превратить 
ааа? в структуру данных, с которой во время выполнения можно делать две разные 
вещи: 


® скомпилировать в исполняемый делегат, просто вызвав ада? .Сопр11е (); 


® просматривать иерархию выражений (здесь это единственный узел Ава, прини- 
мающий два параметра). 


Более того, данными дерева выражений можно манипулировать во время выполне- 
ния, а затем скомпилировать их в исполняемый код. 

Для чего все это может понадобиться? Это не просто возможность написания при- 
чудливого, самоизменяющегося кода, который поставит в тупик вапгих коллег (хотя есть 
и такой вариант). Главная цель — позволить передавать код в виде параметра в методы 
АРГ-интерфейса — не только, чтобы выполнить его, а чтобы передать некоторое другое 
намерение. Например, метод АЗРМЕТ МУС по имени нп] .АсЕ1оп110пК<Т> принимает 
параметр типа Ехркезз1оп<Ас1оп<тТ>>. Он вызывается следующим образом: 


Неп1.Асетоп1пК<НомеСопеко11ег> (с => с.Тадех ()) 


Лямбда-выражение компилируется в иерархию, состоящую из единственного узла 
МесвоаСа11, специфицирующего метод и параметры, на которые указывает ссылка. 
Платформа АЗР.МЕТ МУС не компилирует и не выполняет выражение; она просто на- 
ходит контроллер и действие, на которые произведена ссылка, а затем вычисляет соот- 
ветствующий ОЕ. (согласно сконфигурированной маршрутизации) и возвращает гипер- 
ссылку НТМЕГ, указывающую на этот ОВ. 


Интерфейс точегуаЪ1е<т> и ИМО о $01 


Взяв на вооружение лямбда-выражения, вы можете делать некоторые действитель- 
но умные вещи. В .МЕТ 3.5 имеется важный новый стандартный интерфейс по имени 
ТОцегкуаю1е<Т>. Он представляет отложенные запросы, которые могут быть скомпили- 
рованы во время выполнения не только в исполняемый код .МЕТ, но теоретически во все 
что угодно. Самое замечательное, что компонент 1ЛМО © $ОГ. (включенный в .МЕТ 3.5) 
предоставляет объекты ТОцегуа61е<Т>, которые могут быть преобразованы в запросы 
ЭОГ.. Например, в коде можно построить запрос вида: 


уах мешрегз = (Ехом м 1п пурабаСопеехе.сбееТаб1е<Мептфоехг> () 
уреге м.ТГо91пМаше == "Фоеу" 
зе1есё м) .ТоГ1 3% (); 


В резульгате будет получен параметризированный (и устойчивый от атак внедрени- 
ем в ЭОГ) запрос к базе данных, который показан ниже: 


ЗЕТЕСТ [40]. [Мепректр], [%0].[Ъо910Мате], [40]. [Вероса&1опРо1пе3] 
ЕВОМ [4950]. [Мепфегз] Аз [&0] 

ИНЕВЕ [0]. [Тод1пМапе] = @ро 

{Рагамз: @р0 = 'Зоеу!' } 


Как же это работает? Для начала разобьем одну строку кода С# на три части: 


// [1] Получить ТОоегуаБ1е для представления таблицы базы данных 
Точегуаь1е<Мепьех> пешьехзТаЪ1е = шубафаСопеех® .СееТаЪ1е<МепЪехг> (); 
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// [2] Преобразовать первый ТОцегуаЪ1е в другой, 


// предварив его лямбда-выражением с узлом Иеге () 
ТОчегуаЪ1е<МепЬег> <чаегу1 = шетрегзТаЪ1е .\МЪехге (п => ш.Тод1пМаме == "Фоеу"); 
// -.. или использовать этот синтаксис, 


// который после компиляции будет эквивалентным 

ТОцекгуаБ1е<Мепоет> чиегу2 = Егой м 1п пептрегзТаЬ1е 
уреге п.№од1пМаше == "Фоеу" 
зе1тесЕ п; 


// [3] Теперь выполнить запрос 
ТЬ15е<МепЬех> гез11$ = диеху1.Тор 156 (); 


После птага [1] имеется объект типа бузееп.Рафа.Г1па.Таю1е<Мепфех>, реализую- 
щий ТОцегуа1е<Мепъек>. Класс Таь1е<Мепюег> обрабатывает различные связанные 
с 5ОТ, понятия, такие как соединения, транзакции и тому подобное, но что более важ- 
но — он хранит объект лямбда-выражения, который в данный момент представляет со- 
бой просто СопзфапЕЕхргезз1оп, указывающий на себя (пепфегзТаЪ1е). 

На птаге [2] вызывается не Епошегаю1е .ИТеге () (расширяющий метод \Теге (), ко- 
торый работает на ТЕпитегаю1е), а ОцегуаЮ1е .ИЪеге () (расширяющий метод Ипеге (), 
работающий на ТОцегуаь1е). Это потому, что пемюегзТа1е реализует интерфейс 
ТОчекуаь]е, имеющий приоритет перед ТЕпомекаь]1е. Несмотря на идентичность син- 
таксиса, это совершенно другой расширяющий метод, который ведет себя совершенно 
иначе. Что делает ОцегуаЬ1е .ИВеге () ? Он берет лямбда-выражение (в данный момент 
просто СопзбапеЕхргезз1оп) и создает из него новое лямбда-выражение: иерархию, 
описывающую предыдущее лямбда-выражение и указанный вами выражение-предикат 
(се. м => ш.Го910Маше == "Зоеу") (рис. 3.10). 


\МегеЕхргез 1юп 


СопатЕхргезюЮп ТатббаЕхргез$юп 


тетьегзТае т => т одтМате == "уоеу" 


Рис. 3.10. Дерево лямбда-выражения после вызова \Теге () 


Если вы специфицируете более сложный запрос или построите запрос за несколь- 
ко птагов. добавив дополнительные конструкции, произойдет то же самое. База данных 
при этом не участвует — каждый расширяющий метод Оцегуаь1е .* просто добавляет 
дополнительные узлы к внутреннему лямбда-выражению, комбинируя его с любыми 
лямбда-выражениями, которые передаются в качестве параметров. 

И, наконец, на птаге [3], во время преобразования объекта тдиекуаЮ1е в 11$ или 
иного перечисления его содержимого, “за кулисами” осуществляется проход по внутрен- 
_ нему лямбда-выражению с рекурсивным преобразованием его в синтаксис ЗОГ. Это да- 
леко не простой процесс: для каждой операции языка С#, которую можно использовать 
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в лямбда-выражениях, предусмотрен специальный код; распознаются даже специфиче- 
ские вызовы общих функций (например, зЕх1п9.5сакезМ1 ет ()). В результате иерархия 
лямбда-выражения может быть “скомпилирована” в максимально чистый ЗОГ. Если в 
лямбда-выражении присутствуют такие вещи, которые представить в ЗОГ, невозможно 
(например, вызовы пользовательских функций С#). ищется путь опроса базы данных 
без них, а затем производится фильтрация или трансформация результирующего на- 
бора за счет вызова пользовательской функции С#. Несмотря на сложность, подобным 
образом выполняется успешная работа по генерации аккуратных ЗОГ-запросов. 


На заметку! ЦМО ® ЗО также добавляет дополнительные средства ОВМ, которые не встроены в 
инфраструктуру запросов ТОиегуаЪ1е<Т>, такие как возможность отслеживания изменений, 
проводимых в любых объектах, которые она возвращает, с последующей записью этих изме- 
нений в базу данных. 


ЫМО то Еуегуйт9 


Интерфейс ТОчекуаю1е<Т> предназначен не только для применения вместе с ЛМО 
фо 5ОГ. Те же операции запросов и возможности для построения деревьев лямбда-выра- 
жений можно использовать для опроса любых источников данных. Это может оказаться 
непросто, но если вы найдете способ интерпретировать деревья лямбда-выражений не- 
которым специальным образом, то сможете создать собственный “поставщик запросов”. 
Другие проекты ОКМ уже приступили к добавлению поддержки ТОцегуаБ1е<Т> (напри- 
мер, ТЛ\МО о МНЪегпа®), и начинают появляться поставщики запросов для МУЗОТ, хра- 
нилицщ данных ГОАР файлов ВОЕ, ЗВагеРой и т.д. В качестве примера оцените эле- 
гантность ММО © Атал7оп: 


уаг пусВоок$ = Еком Боок 1п пем Атагоп.ВооКЗеаксй () 
мпеге Боок.Тле1е.Сопбсатиз ("АЗР.МЕТ МУС") 
&& (БооКк.Рг1се < 49.95) 
&& (Боок.Сопд1Е1лоп == ВоокКСоп911оп.Мем) 
зетесе Боок; 


Резюме 


В этой главе вы ознакомились с основными концепциями, положенными в основу 
АЗРМЕТ МУС, а также инструментами и приемами, необходимыми для успешной веб- 
разработки на основе новейших технологий .МЕТ 3.5. В следующей главе вы примени- 
те эти знания для создания реального приложения электронного магазина на АЗРМЕТ 
МУС. комбинируя архитектуру МУ.С, слабо связанные компоненты. модульное тестиро- 
вание и чистую модель предметной области, построенную с помощью ММО то $501. 


ГЛАВА 4 


Реальное приложение 
эрог6Зоге 


ы уже знаете преимущества платформы АЗР.МЕТ МУС и ознакомились с некото- 

рыми теоретическими концепциями, лежащими в ее основе. Теперь наступило 
время запустить платформу в действие и посмотреть, как все ее преимущества прояв- 
ляются в реалистичном приложении электронного магазина. 

Разрабатываемое приложение, называемое Зрогоге (магазин спорттоваров}, будет 
следовать классическим метафорам проектирования мест онлайновой торговли: в нем 
будет предусмотрен каталог товаров. просматриваемый по категориям. индексная стра- 
ница, корзина для покупок, куда посетители могут добавлять и удалять наименования 
и количество товаров, а также экран подтверждения заказа, где посетители могут вво- 
дить детальную информацию о доставке. Зарегистрированным администраторам сайта 
предлагаются средства СВОД (сгеа{е, геа@, ирдайа, айее — создание, чтение, обновле- 
ние, удаление) для управления каталогом товаров. Преимущества АЗРМЕТ МУ.С и свя- 
занных с ним технологий можно будет оценить, выполнив следующие условия. 


® Тщательное соблюдение архитектурных принципов МУС, дополненное примене- 
нием СазЦе УЛпазог и контейнеров инверсии управления (ЮС). при построении 
компонентов приложения. 


® Создание многократно используемых частей пользовательского интерфейса с помо- 
щью частичных представлений и вспомогательного метода Не1 .ВепаегАс®1ол (). 


® Применение Зузен1 \еЬ.ВоиНпз для получения чистых ОВ, оптимизированных 
под поисковые механизмы. 


® Использование ЭСТ. Зегуег, МО о ЗОГ, и шаблона проектирования репозиториев 
для построения каталога товаров на основе базы данных. 


® Создание подключаемой системы для обработки готовых заказов (реализация по 
умолчанию будет отправлять детали заказа по электронной почте администрато- 
ру сайта). 


® Применение аутентификации с помощью форм АЗРМЕТ Еогил$ АитепйсаНоп в 
целях безопасности. 


96 — Часть 1. Введение в АЗРМЕТ МУС 


На заметку! Эта глава посвящена не демонстрационному программному обеспечению'. Она рас- 
скажет о построении солидного, полезного приложения на основе правильной архитектуры 
и современного передового опыта разработки. В зависимости от вашего опыта, некоторым 
предмет зтой главы может показаться слишком медленным способом построения слоев ин- 
фраструктуры. В самом деле, применяя традиционную технологию АЗР.МЕТ М/еБРогтз, вы оп- 
ределенно можете получить видимые результаты быстрее, перетаскивая и расставляя элемен- 
ты управления, непосредственно привязанные в базе данных 301. 


Однако, как вы убедитесь, начальные вложения в ро" юге с лихвой окупятся, обеспечив со- 
провождаемый, расширяемый, хорошо структурированный код, отлично поддающийся авто- 
матизированному тестированию. Вдобавок, как только основная инфраструктура будет готова 
{к концу этой главы), скорость дальнейшей разработки радикально возрастет. 


Мы разобьем процесс построения приложения на три этапа. 


® В этой главе будет создана основная инфраструктура, или “скелет”, приложения. 
Он включит в себя базу данных ЗОГ, контейнер оС, черновой готовый каталог 
товаров и быстрый веб-дизайн на основе С$$. 


® В главе 5 будет разработана основная часть средств приложения, видимых извне, 
включая навигацию по каталогу, корзину для покупок и процесс оформления заказа. 
® В главе 6 будут добавлены средства администрирования (те. СВОЮ для управ- 


ления каталогом), аутентификация и экран входа, а также финальное расшире- 
ние — возможность для администраторов загружать изображения товаров. 


Модульное тестирование и разработка, управляемая тестами 


Платформа АЗРМЕТ М\УС спроектирована с поддержкой модульного тестирования. На протяже- 
нии трех глав вы увидите его в действии, разрабатывая модульные тесты для множества средств 
и функций приложения Зрои$оге с использованием двух популярных инструментов тестирования 
с открытым исходным кодом — МОП и Мод. Это потребует написания некоторого дополнитель- 
ного кода, но обеспечит значительные преимушества. Как вы увидите, это не только повысит со- 
провождаемость в долговременной перспективе, но также поможет в короткие сроки построить 
более ясную архитектуру приложения, потому что тестируемость стимулирует правильное отде- 
ление компонентов приложения друг от друга. 


Материал, посвященный исключительно тестированию, в этих трех главах будет выделяться во 
врезки вроде этой. Если модульное тестирование или разработка, управляемая тестами (ТОО), 
вам не интересна, можете пропускать такие врезки (от этого приложение Зро\$Тоге работать не 
перестанет). Это доказывает, что АЗРМЕТ М\С и модульное тестирование/ТОВ — абсолютно раз- 
ные вещи. Чтобы воспользоваться преимуществами АЗР МЕТ МУС, выполнять автоматизирован- 
ное тестирование не понадобится. Помните, что пропуская врезки, посвященные тестированию, 
вы можете не понять некоторые части проекта приложения. 


Итак, в зтих главах методика ТОО демонстрируется только там, где это имеет смысл. Многие 
средства проектируются и определяются за счет написания тестов перед написанием их при- 
кладного кода, что стимулирует написание такого кода, который бы обеспечил успешных прогон 
этих тестов. Однако в целях удобства чтения и по той причине, что книга посвящена преимуще- 
ственно АЗРМЕТ М\С, а не ТОО, в данной главе выбрана прагматичная нестрогая форма ТОО. Не 
вся логика приложения создается в ответ на проваленные тесты. В частности, вы обнаружите, 

что тестирование вообще не начинается до тех пор, пока не будет готова инфраструктура оС. 


Под демонстрационным программным обеспечением (4егзо\маге) подразумевается про- 
граммное обеспечение, разработанное с использованием “быстрых трюков”, которые хоро- 
шо выглядят в 30-минутной презентации, но совершенно неэффективны в крупном реаль- 
ном проекте (если только вы не испытываете удовольствия от ежедневного распутывания 
клубков загадок). 
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После этого основное внимание будет уделяться проектированию контроллеров и действий через 
тесты. Если вы ранее не имели дело с методикой ТОО, то даже такой упрощенный подход даст 
хорошее представление об этом предмете. 


Приступаем 


Прежде всего, вовсе не обязательно читать эти главы, сидя перед компьютером и за- 
нимаясь написанием кода. Описания и снимки экранов должны быть достаточно ясны, 
даже если вы читаете, сидя в ванной?. Однако если вы хотите следить за изложением, 
занимаясь написанием кода, понадобится тотовая среда разработки, включающая сле- 
дующие средства: 

1. Увиа]1 Зыааю 20083. 

2. АЗРМЕТ МУС версии 1.0. 


3. БОГ Зегуег 2005 или 2008 в виде бесплатной версии Ехргезз (доступной по адресу 
УТУ - ТЯ сГОЗОЕЕ . со/ 591 /е91Е1005/ехргезз/) либо любой другой. 


Для получения и установки АЗРМЕТ МУС и ЗОК 2008 Ехргезз можете использовать ЖЕБ 
Раогти ГазфаПег (или. п1скозоЕе .соп/иеь/); подробная информация по этому поводу да- 
валась в главе 2. Позднее в главе также понадобятся несколько бесплатных инструментов 
и каркасов с открытым кодом. Они будут представлены по ходу изложения материала. 


Создание решений и проектов 


Чтобы приступить к работе, откройте \Азца! З6лато 2008 и создайте новое пустое ре- 
шение по имени 5рогЕ боге (выберите пункт меню Ейе=>Мем>Ргоес" (Файл=>Создать=> 
Проект), в отобразившемся окне укажите Отег Ргфесе Турез=>\Мвиа! Зиаю Зоибопз 
(Другие типы проектов->Решения Увиа!] За@10) и затем Вйапк Зомбоп (Пустое решение). 

Если вы уже занимались разработкой в среде \У1зиа! Эва ранее, то знаете, что с 
целью управления сложностью решения подразделяются на коллекции подпроектов, тде 
каждый проект представляет отдельную часть приложения. В табл. 4.1 описана струк- 
тура решения, используемого при создании этого приложения. 


Таблица 4.1. Проекты, которые должны быть добавлены к решению ЗрохЕ$ Фоге 


Название проекта Тип проекта Назначение 


Ропа1пМоде1 Библиотека классов С# Содержит сущности и логику, связанную с пред- 
метной областью, которая подготовлена к посто- 
янному хранению в базе данных через репозито- 
рий, построенный с помошью ИМО ю 5СЕ. 


Мероит Веб-приложение АБРМЕТ МУС — Содержит контроллеры и представления при- 
ложения; служит пользовательским веб-ин- 
терфейсом для рота1пМоде1. 


ТезЕ$ Библиотека классов С# Содержит модульные тесты для 


Ропа1пМоде1 имеЪот. 
—_—___ д 


Что, вы так и делаете? Тогда серьезно — отложите лаптоп в сторону! Вряд ли получится 
устроить его на коленях... 


3 Вообще говоря, создать этот код можно и в бесплатной среде У1зиа! \еЪ Оеуеюрег 2008 
Ехргезз Е@оп с 5Р1 (вот уж название так название), хотя предполагается использование 
среды У1за1 Эёаа1о. 
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Добавьте по очереди все три проекта, щелкая правой кнопкой на имени решения 
(например, зрогезеоге) в ЗиНоп Ехрогег и выбирая в контекстном меню пункт 
АЧЧ->Мем/ Рго]ес+ (Добавить=>Новый проект). При создании проекта МеБОТ среда \1зиа1 
ЗА ю отобразит окно с запросом: У/оца уоц Ше то сгеае ип {е5 ргдес{ Гог 15 аррИса- 
Ноп? (Хотите ли вы создать проект модульных тестов для этого приложения?). Так как 
планируется соэдавать его вручную, щелкните на кнопке Мо (Нет). 

По окончании структура решения должна выглядеть примерно так, как показано на 
рис. 4.1. 


21 7 
яя Зоо брег оге' 3 ргозесн} 
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Я Тез 
Розы Ресрее5 


эя Ребегемсез 
8] Саез.с5 
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Рис. 4.1. Начальная структура решения 


Можете удалить оба файла С1аз31.с3, автоматически добавленные \У15иа! Эва. 
Для облегчения отладки удостоверьгесь, что Мерот помечен как начальный проект по 
умолчанию (выполните щелчок правой кнопкой мыши на его имени и выберите в кон- 
текстном меню пункт 56 а$ За Ур Ргоеси (Установить как начальный проект) — его 
имя выделится полужирным). Теперь можно нажать <ЁР5> для компиляции и запуска 
решения (рис. 4.2)*. 
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Рис. 4.2. Запуск приложения 


“Если будет предложено модифицировать файл меб. сопЕ1д для включения отладки, 
соглашайтесь. 
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Если все описанное выше получилось сделать, значит, среда разработки \15$иа1 
ЭбаЧю/АЗРМЕТ МУС работает исправно. Остановите отладку, закрыв окно Биёегпей 
Ехрогег или переключившись в \15иа! За и нажав <ЗАНЕЕБ>. 


Совет. При запуске проекта нажатием <Е5> запускается отладчик \М5иа! Зо и открывается но- 
вый веб-браузер. В качестве быстрой альтернативы оставьте приложение открытым в отдель- 
ном экземпляре браузера. Для этого, при условии, что отладчик запускался хотя бы однажды, 
найдите в системном лотке пиктограмму АЗР.МЕТ Оем@ортеге Зегуег (Сервер разработки 
АЗРМЕТ), как показано на рис. 4.3, щелкните на ней правой кнопкой мыши и выберите в кон- 
текстном меню пункт Ореп ш \/еБ Вгом/5ег (Открыть в веб-браузере). 


После этого при каждом изменении приложения Зро$ ге не придется заново запускать сеанс 
отладки для его проверки. Понадобится просто перекомпилировать решение, переключиться на 
этот отдельный экземпляр браузера и щелкнуть на кнопке Обновить (Е 5). Это намного быстрее! 


Ореп, м ЗМеБ Вгомезег 


Щелкните на пиктограмме 
правой кнопкой мыши 


© 


ор 


Эно: ОезайЕ |4 


Зое Расе - МН... < 9 Ф 12 


Рис. 4.3. Запуск приложения в отдельном экземпляре браузера 


Построение модели предметной области 


Модель предметной области — сердце приложения. поэтому имеет смысл начать с 
нее. Поскольку это будет приложение электронного магазина, наиболее очевидная сущ- 
ность предметной области, которая понадобится — это товар. Создайте новую папку по 
имени Епё161ез внутри проекта Рота1пМоде1 и добавьге новый класс С# под названи- 
ем рго@асе (рис. 4.4). 


Зорииут Бхрогег = Зошной "Эройзяное' {3 ртсресё? е “ *зх 
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жа Ргорегнея 


а ВЕРЕнелсея 
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„ СВ мвыя 


Рис. 4.4. Добавление класса Реодасе 


Пока трудно сказать точно, какие свойства должны быть предусмотрены для описа- 
тия товара, так что давайте начнем с наиболее очевидных. Если потребуются другие, 
вы всегда сможете добавить их позже. 
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патезрасе Рома1пМоде1 .Ет 1 (1е$ 
{ 
ра611с с1азз РкодисЕ 
{ 
роБ11с 106 РкодасЕТЬ { дее; зе®; } 
роЬ11с зЕк1па Маше { чеё; зе\; } 
роаБ11с $зЕг1па Резск1ретоп { де; зет; } 
руБ11с аес1та1 Рг1се { дее; зе; } 
роЬ11с зеглпа Сабедоку { деё; зе; } 


} 


Конечно, этот класс должен быть помечен как руБ11с, а не 1п%6егпа1, поскольку 
нужно обеспечить доступ к нему из других проектов. 


Создание абстрактного репозитория 


Нам понадобится какой-то способ получения сущностей РгодисЕ из базы данных, 
а, как известно из главы 3, логику постоянного хранения имеет смысл помещать не в 
сам класс Ркгодис®, а держать отдельно, для чего воспользоваться шаблоном Керо$йогу 
(репозиторий). Давайте пока не будем беспокоиться о том, как должен работать внут- 
ренний механизм доступа к данным, а пока просто определим интерфейс для него. 
Создайте новую папку верхнего уровня внутри Ропа1пМоде1 под названием Арзегкасе 
и добавьге в нее новый интерфейс? — тРгодисеВероз1®огу: 
папезрасе Пота1пМоде1 .Абзекасе 
{ 
рою11с 1пеекЕасе ТРгодосеВероз1®огу 
{ 
ТОцегуаЬ1е<Ркодис®> Ркодиас®з { деё; } 


} 


В этом коде используется интерфейс ТОцегуаю1е для публикации объектно-ори- 
ентированного представления некоторого внутреннего хранилища данных Ргодасе 
(не углубляясь в детали работы хранилища данных). Потребитель интерфейса 
ТРкодисезВероз16оку может получить актуальные экземпляры Ркодисе, соответствую- 
щие спецификации (те. запросу 11Л№0), ничего не зная о хранилище или механизме их 
извлечения. В этом и состоит сущность шаблона ВерозНогу®. 


Внимание! На протяжении этой главы (и всей книги) вы не встретите частых напоминаний по по- 
воду добавления операторов из1п9а для всех необходимых пространств имен. Это потребова- 
ло бы слишком много места, было бы утомительным, да и все равно вы легко догадаетесь о 
необходимости их добавления. Например, если сейчас попробовать скомпилировать решение 
(нажав <С+1+5 НИ +В>), появится сообщение об ошибке ТНе {уре ог патезрасе ”РгодисЁ 
соша по! Бе Юилпа (Тип или пространство имен Рго@ись не найдено}; по нему неслож- 
но догадаться, что нужно добавить оператор 13119 Рома1пМоЯе1.ЕпЕ1Е1ез; в начало 
ТРгодисе5Вероз1е0ку.с$. 


5 Щелкните правой кнопкой мыши на папке Абэгаси, выберите в контекстном меню пункт 
Аа Мем Мет (Добавить>Новый элемент) и затем выберите ШеЧасе (Интерфейс). 


Примечание для энтузиастов тпаблонов проектирования: первоначальное определение ре- 
позитория, данное Мартином Фаулером и Эриком Эвансом, предшествовало элегантному 
АР!-интерфейсу тОоцегуаЬ1е и потому требует больше ручной работы для реализации. Но 
конечный результат, если считать запросы ММО спецификациями, по сути, тот же самый. 
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Вместо того чтобы делать это вручную, поместите каретку на имя класса-виновника ошибки в исхол- 
ном коде (в данном случае — на имя Ргоисе, которое будет подчеркнуто, что обозначает ошибку 
компиляции) и нажмите <Си|-.>. Среда \зца! Зи ю определит, какое пространство имен необхо- 
димо импортировать, и добавит оператор из1п9 автоматически. (Если это не сработает, эначит, 
либо неправильно введено имя класса, либо в проект должна быть добавлена ссылка на сборку. 
В последующих описаниях проектов всегда будет указано, на какие сборки необходимо ссылаться.) 


Создание фиктивного репозитория 


Теперь, имея абстрактный репозиторий, можно создать его конкретную реализа- 
цию, используя для этого любую базу данных или технологию ОБМ по своему выбору. 
Это довольно кропотливая работа, поэтому давайте пока не будем отвлекаться — фик- 
тивного репозитория на основе коллекции объектов в памяти вполне достаточно для 
обеспечения некоторого действия в веб-браузере. Добавьте еще одну папку верхнего 
уровня по имени Сопсгете в Рота1пМоае1 и поместите в нее класс С# под названием 
ЕаКеРгодисеВероз1тогу . сз: 


памезрасе Рота1пМоае1 .СопсгеЕе 
{ 
руч11с с1азз РГакКерРходисезВероз16огу : ТРЕОЗисЕзВероз$1еоку 
{ 
// Фиктивный жестко закодированный список товаров 
рглуафе этаЕ1с ТОпегуаб1е<Рко@дисЕ> ЕакКерРгодосе$ = пем 115Е<РгодисЕ> { 


пеи РгоисЕ { Маме = "РооЕра11", Рхлсе = 25 }, 
пеи РкоацсЕ { Маме = "бикЕЁ Боаг@а", Рклсе = 179 }, 
пем РкоЯосЕ { Маше = "Випплид зроез", Рхг1се = 95 } 


}.АзОцекуаю1е(); 
рою11с ТОцекуа51е<РкоаисЕ> Ргодис®$ 
{ 


деф { хгебаки ЕакКеРгодосев; } 


Совет. Самый быстрый способ реализации интерфейса предусматривает ввод имени интерфей- 
са (например, руЪ11с с1аз5з ЕакергодисезВероз1еогу : ГргодисезВероз1фоху}, 
щелчок правой кнопкой мыши на имени интерфейса и выбор в контекстном меню пункта 
нпр!етепЕ и1еГасе (Реализовать интерфейс). Среда \Мзиа! Зи добавляет набор заготовок 
методов и свойств, удовлетворяющий определению интерфейса. 


Отображение списка товаров 


Остаток дня вполне можно было бы потратить на добавление средств и поведения к 
модели предметной области, проверяя с помощью модульных тестов каждый поведен- 
ческий аспект, и при этом не касаясь ни проекта веб-приложения АЗРМЕТ МУС (Неьот), 
ни даже веб-браузера. Такой подход хорош при наличии нескольких разработчиков в 
команде, каждый из которых занимается своим компонентом приложения. Он также 
приемлем, когда имеется четкое представление о необходимых средствах модели пред- 
метной области. Но в данном случае вы строите все приложение в одиночку, поэтому 
хочется как можно скорее получить наглядные результаты. 

В этом разделе вы приступаете к использованию АЗРМЕТ МУС, создав класс кон- 
троллера и метод действия, который может отобразить список товаров из репозитория 
(поначалу — из гакерРходасезВероз1когу). Начальная конфигурация маршрутизации 
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будет настроена так, чтобы список товаров появлялся, когда посетитель обращается в 
браузере к домашней странице приложения Эро юге. 


Удаление ненужных файлов 


Как и в примере Райушуйез из главы 2, мы удалим из проекта Иерот набор ненуж- 
ных файлов. которые по умолчанию включаются шаблоном проекта АЗРМЕТ МУС. Для 
Эрот юге нам не нужен скелет мини-приложения. потому что он затруднит понимание 
того, что происходит. Таким образом, воспользуйтесь ЗоплНоп Ехрогег для удаления из 
проекта МеьОТт следующих папок и файлов: 


® /Арр Раба 
® /Сопрепе/51е.сзз 


® /СопЕго11егз/НомеСопехо11ег.сз и /СопЕхо11егз/АссоцпЕСорего11ех. сз 
(во оставьте папку /Сопего11егз) 


® папки /\У1еиз/Ноте и /У1еиз/Ассоципе вместе со всеми файлами 
® /\1емз/5Вагеа/Еггог.азрх 
® /\1емз/5Багед/ТочОпОзехСопего1.азсх 


После зтого останутся только самые базовые механизмы и ссылки на сборки, необ- 
ходимые для АЗРМЕТ МУС, плюс несколько файлов и панок, которые будут использо- 
ваться позже. 


Добавление первого контроллера 


Имея такой чистый фундамент, можно приступать к построению набора контролле- 
ров, действительно необходимых приложению. Начнем с добавления первого контрол- 
лера, который будет отвечать за отображение списка товаров. 

Вокне оплот Ехрогег щелкните правой кнопкой мыши на папке Сопего11егз (в про- 
ектемеьот)и выберите кконтекстном меню пунктАЧ => Сотто!ег (Добавить=>Контроллер)}. 
В появившемся окне приглашения введите Рходисе$Сопего11ех. Не отмечайте флажок 
АСД асбоп те#од$ ог Сгеае, Урдае, апа Беай$ зсепайо$ (Добавить методы действий 
для сценариев создания, обновления и удаления), потому что эта опция генерирует 
крупный блок кода, который здесь не нужен. 

Удалите стандартные заготовки методов действий, которые У1зпа1 ЗёлАю сгенериру- 
ет по умолчанию, оставив класс Родос 5Сопего11ех пустым: 


патезрасе МеБот .СопЕхо11ет$ 

{ 
РЧЬ11с с1азз РходасезСоп+ко11ек : Сопёхго11ег 
{ 
} 

} 


Чтобы отобразить список товаров, РеодисЕСорЕго11ех должен обращаться к дан- 
ным о товарах, используя ссылку на некоторый интерфейс ТРходисе5Вероз1оху. 
Поскольку этот интерфейс определен в проекте Рота1юМоае1, добавьте в МеБот ссыл- 
ку на проект Ропа1пМодел”. Благодаря этому, РЕОЧисЕзСопего11ех получает доступ к 
ТРкодис&зВероз1Согу через переменную-член, заполненную в конструкторе: 


7 В окне Зол6оп Ехрогег щелкните правой кнопкой мыши на имени проекта МеБОТ и выбери- 
те к контекстном меню пункт Ада Веегепсе (Добавить ссылку). На вкладке Ргоес$ (Проекты) 
открывшегося окна выберите ромалиМоде1. 
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рор11с с1аз$ РкодисезСопего11ег : Сопеко1Лех 
{ 
рхауафе ТРкодис&Вероз1фогу ргодис+Вероз1оху; 
рчЬ11с Ргобясе$Сопеко11ех () 
{ 
// Это временно, пока не будет готова инфраструктура 
ркодисЕзВероз1фоку = пем ЕакеРгодисеВероз1огу(); 


На заметку! Чтобы это скомпилировалось, понадобится также добавить операторы из1па 
Рота1пМоде1.Арзегасе; и пз1па Рота1пМо4е1 .Сопскете;. Это последнее напоми- 
нание о пространствах имен; далее вы должны не забывать делать это сами. Как было описано 
ранее, среда \Мзца! Зи сама найдет и добавит корректное пространство имен, когда вы ус- 
тановите каретку на соответствующее имя класса и нажмете комбинацию <СН+.>. 


На данный момент контроллер имеет жестко закодированную зависимость от 
ЕакеРгодисезВероз1®огу. Позднее вы избавитесь от этой зависимости, применив кон- 
тейнер 1оС, а пока стоит заняться построением инфраструктуры. 

Добавьте метод действия 1135 (), который визуализирует представление, демонст- 
рирующее полный список товаров: 


руЮ11с с1азз РкодисЕ$Сопего11ехг : Сопего1Лех 
{ 
ргетуасе ТРкодис®5Веро51Еогу ркодисЕ$Вероз1фоку; 
рую11с Ргодасе$СопЕго1Тех () 
{ 
// Это временно, пока не будет готова инфраструктура 
ргоаисЕзВероз1фогу = пем ГаКерРходис+$Вероз1Еогу (); 


} 
руь11с У1емВезо1 11% () 


{ 


хебагр Узем (ргодисЕВероз1фогу.Рко@ис+$ .ТоГ1зе()); 


} 


Как говорилось в главе 2, подобный вызов \У1ем () (без явного имени представления) 
заставляет АЗРМЕТ МУС визуализировать “стандартный” шаблон представления для 
метода Т150(). Передавая рходисе;Вероз1оху.Ргодисез.Тор1 зе () методу У1еи (), 
мы заставляет его наполнить Моде] (объект, используемый для отправки строго типи- 
зированных данных глаблону представления) списком объектов-товаров. 


Настройка маршрута по умолчанию 


Итак, у вас есть классе контроллера, указывающий на некоторые подходящие для 
визуализации данные, но каким образом МУС узнает, когда вызывать его? Как упоми- 
налось ранее, существует система маршрутизации, которая определяет, как ОЕ, ото- 
бражаются на контроллеры и действия. Сейчас мы настроим конфигурацию маршру- 
тизации, которая ассоциирует корневой ОЕ, сайта (Бе®р: //сайт/) с действием 1,15% () 
контроллера РгодисеСопего11ехг. 

Взтлянем на код в файле С1ора1 .азах.сз (корень МеьОТ): 


риб11с с1азз МусАрр11саЕ1оп : бузЕет.Иер. НЕБрАрр11сае1оп 
{ 
рур11с зЕаЕ1с уо1а Вед1зЕекВочеез (ВоиеСо11есЕ1оп гопЕез} 


{ 
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хоцЕез .ТдпокеВоп*е (" {хезоцгсе} .аха/ { *раЕ1тЕо}"); 
хосЕе$ .МарВоцете ( 


"РеЁао1", // Имя маршрута 
" { сопЕко11ег} / {асЕ1оп}/{1а}", // ОВЬ 
пем { сопЕго11ех = "Нопе", ас®1оп = "Тпдех", 1а ="" } // установки 


// по умолчанию 
}; 
} 
ркотестей уо1а Арр11саблоп Зак () 
{ 


Вед1эсегВоцЕе$ (ВоисеТаь1е.Вопеез) ; 


} 


Подробные сведения о маршрутизации будут даны в главе 8, а пока достаточно 
знать, что этот код запускается при первоначальном старте приложения (см. обработ- 
чик Арр11са&1оп_5%ах®) и конфигурирует систему маршрутизации. Эта конфигурация 
по умолчанию отсылает посетителей к действию под названием Тпдех контроллера 
НопеСопего11ехг. Но все это уже отсутствует в проекте, потому обновите определение 
маршрута, заменив его действием по имени 113+ из Рходис®* Сорего11ег: 


гоцЕевз .МарВои*е ( 


"РеЁац1е", // Имя маршрута 
" { сопЕго11ек} / {асЕ1оп}/{1а}", // ОВЬ 
рем { сопЕго11ех = "Ркодисез", асфЗоп = "1154", 13а ="" } // Установки 


// по умолчанию 

}; 

Обратите внимание, что понадобилось написать только Ргодисез, а не 
РкодисЕзСопЕго11етг — это одно из соглашений об именовании, принятых в АЗРМЕТ 
МУС (имя класса контроллера всегда закончивается фрагментом СопЕхо11ех, и эта 
часть из элементов маршрута исключается). 


Добавление первого представления 


Если в данный момент запустить проект, то будет выполнен метод 113% () класса 
РгоаисЕзСопего11ех, однако он сгенерирует ошибку со следующим сообщением: ТПе 
мем/ ‘5 ог И тазег сош@ по! Бе юипа. ТВе юйомипа юсаНопз$ меге зеагснел: -/\Лем5/ 
Ргодис13/Ызт.азрх ... (Представление “Т45Ё или его владелец не найдены. Поиск выпол- 
нялся в следующих местоположениях: -/\У1е\з/РгоЧис3/Тл8Ё.азрх .. .). Это объясняется 
тем, что вы предписали визуализировать представление по умолчанию, тогда как оно не 
существует. Самое время создать его. 

Вернитесь к файлу РгодисезСопеко11ек.сз, щелкните правой кнопкой мыши в 
теле метода 115%() и выберите в контекстном меню пункт АФЯ \Мем (Добавить пред- 
ставление). Это представление будет визуализировать список экземпляров Рходиск, по- 
этому в появившемся всплывающем окне отметьге флажок Сгеа@ а энопо\ Ттуред мем 
(Создать строго типизированное представление), а в раскрывающемся списке Меми дайа 
са5$ (Класс данных представления) выберите класс Ропа1пМоде1 .Епе1е1ез.Ргодисе. 
Мы будем визуализировать последовательность товаров, а не единственный товар, 


поэтому заключите имя, выбранное в списке \Ме\м/ даа с!а$$, в ТЕпомехаБле<...>8. 


8 Можно было бы использовать 11,1 5<РхобисЕ> или даже 115 <Ргодосф>, но нет причин 
требовать такого специфического типа, когда подойдет любой ТЕпомега51е<Рходисе>. 
Вообще говоря, всегда лучше применять наименее ограничивающий тип, который отвечает 
существующим потребностям (тип, который и необходим, и достаточен). 
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Настройки мастер-страницы по умолчанию можно оставить без изменений, потому что 
в этом примере они будут использоваться. Окончательная конфигурация опций нока- 
зана на рис. 4.5. 
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Рис. 4.5. Опции, используемые при создании представления 
для метода 1,131 () класса РходасЕзСопехо11ех 


После щелчка на кнопке Ааа (Добавить) У1з0а1 361410 создаст новый шаблон пред- 
ставления в месте, выбранном по умолчанию для действия 13%, которым является 
= /У1еиз/Ргоацсез/Т13.азрх. 

Вы уже знаете, что метод Т15%() класса РЕГОодис® 5СопЕго11етг наполняет Моде1 
зкземплярами ТЕпипегаб1е<Ргодис®>, передавая ргодисеВероз1Еохгу. Ркодисее. 
Тор13е() при вызове У1ем (), так что можете заполнить этот базовый шаблон пред- 
ставления для отображения последовательности товаров: 


<%@ Раде Т1Е1е="" Тапдиаде="С#" МазфехРадеР11е="- /У1емз/5Вахед/51{е.МазЕек" 
Тпбег1е5="бузЕет.Иер .Мус .\У1еиРаде<ТЕпанехга1е<Рота1пМоде1 .Еп11ез.Рко@исЕ>>" %> 
<азр:СопЕепЕ СопЕепЕР1асеНо1АаехТО="Т141еСопфеп®" гипае=" зегуег"> 
Ркгодасе5 
</азр:Сопфеп+> 
<азр:Сопфепе СопЕепЕР1асеНо]1Чех1Тр="Ма1пСопЕепЕ" кипаф="зекуег"> 
<% ЕогеасВ (уаг ргодасе 141 Мо@е1) { %> 
<@1у с1азз="1фет"> 
<в3><%= ргодис*.Маме %></В3> 
<$= ркодас+.БезсктреЗоп %> 
<54><%= ргодис+.Рх1се.Тобх1т9 ("с") %></54> 
</а1х> 
<$% } %> 
</азр:Сопфеп®> 


На заметку! В этом шаблоне используется метод форматирования строк .То5Ех1та ("с") , который 
визуализирует числовые величины в виде денежных единиц, соответствующих локальным настрой- 
кам сервера. Например, если сервер настроен в режиме еп-05, то (1002.3) .То5Еглиа ("с") 
вернет $1,002.30, аесли в режиме ха-В0 — то 1 002, З0р. Если приложение должно рабо- 
тать в режиме, отличном от установленного на сервере, добавьте к узлу <зузЕет.иеб> файла 
за .сопЕ1а следующий узел: <91ора11хаЕ1оп со1Еиге="га-ВО" и1Со1оге="ко-ВО" />. 
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И последний момент: откройте мастер-страницу /У1ечз/$вахе/515е.Мазуег и 
удалите из нее почти все, что среда У15ца| За 10 поместила туда по умолчанию, оста- 
вив лишь следующий минимум: 


<%@ Мазфег Еапдиаде="С#" Тпрег1Ез="Зузфет.Иеь.Мус .У1емМазеекРаде" %> 
<!РОСТУРЕ Всп1 РОВЬТС "-//МЗС//РТЬ ХНТМГ 1.0 5ЕаСЕ//ЕМ" 
"БЕСр: //ими.м3 . ога/ТВ/хьт1 1 /РТЬ/хьЕт11-5ЕХАСЕ.Еа"> 
<Ве1 хи п$="ВЕСр: //мии. м3 .ока/1999/хьЕнт "> 
<БеаЯ кипаЕ="зегуег"> 
<Е1Е1е><азр:СопеепЕР1асеНо14Чек тр="Т1Е1еСопеепе" гипаф="зегуех" /></+1Е1е> 
</неаЯ> 
<фоду> 
<азр:СопЕепЕР1асеНо14ег Тр="Ма1пСопфепе" гипа+="зегуех" /> 
</роау> 
</Выи1> 


Теперь можно запустить проект вновь (нажмите <ЕР5> или скомпилируйте и пере- 
грузите страницу, если вы используете отдельный экземпляр браузера). Как видно на 
рис. 4.6, контроллер РХодисЕСопего11ег визуализирует все данные, хранящиеся в 
репозитории гаКеРходасЕВероз1Еоху. 
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Рис. 4.6. РеобисезСопеко11ех визуализирует 
данные из ЕаКергодисе$Вероз1тогу 


Подключение к базе данных 


Появление возможности отображать список товаров из т Ргоаисе5Вероз1Фогу озна- 
чает, что вы на правильном пути. К. сожалению, пока что есть только фиктивный репо- 
зиторий ГакергодисезВероз16охку, который содержит в себе жестко закодированный 
список, а это совершенно не годится для реального приложения. Наступил момент соз- 


дать другую реализацию ТРгодисЕ$Вероз1®оху, на этот раз способную подключаться 
к базе данных ЗОГ. Зегуег. 


Определение схемы базы данных 


Выполняя следующие шаги, вы создадите новую базу данных $ОГ, с таблицей 
РЕОФист5, которая содержит некоторые тестовые данные, используя для этого встро- 
енные в \150а1 561410 2008 средства управления базами данных. То же самое мож- 
но сделать и с помощью инструмента ЗОГ. Зегуег Мапаветеп Зал (или ЗОТ, Зегуег 
Мападететт Збадю Ехргез$ в случае линейки Ехргез$), если вам он больше нравится. 
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В среде \У15на1 Звба1о откройте Зегуег Ехр]огег (через меню \Мем (Вид)), щелкните 
правой кнопкой мыши на узле Эаа Соппесйоп$ (Соединения с данными) и выберите 
в контекстном меню пункт Сгеае Мем ЗОЁ Зегуег Ваара$е (Создать новую базу дан- 
ных ОГ, Зегуе ). Подключитесь к серверу баз данных и создайте новую базу по имени 
Зрохе5еохге (рис. 4.7). 


| Стеае Чем: ЗС: Загуе: Оаабазе 


| Еищег стилайон с соппесу с в 50 Зегоег, Нап зресй: Не 
пате оРа ЧакаБасе То сгеа\е. : 


Зергег пате: 
дЗОЕХРЕЕСЯ Г ев | 


од си 0 Е сеплЕГ 


р Уве 501 Зегиег Аи феиНсаНоп 


Мал датаБазЕ пате; 


Зройз юге 


] 
] 
| 
| 38: Це униасля Рбнепясаной | | 
| 


Рис. 4.7. Создание новой базы данных с использованием ЗОЕ Зегуег Мападетете Зидю 


После создания новая база данных появится в списке соединений с данными окна Зегуег 
Ехрогег. Теперь добавьге новую таблицу (раскройте узел базы данных 5рогЕ5еоге, щелкни- 
те правой кнопкой мыши на узле Та ез (Таблицы) и выберите в контекстном меню пункт 
Ада Мем/ ТаЫе (Добавить новую таблицу)) со столбцами, перечисленными в табл. 4.2. 


Таблица 4.2. Столбцы новой таблицы 


Имя столбца Тип данных Допускает Дополнительные характеристики 
ы ыы значения по11 р р 

Ркодасетр тие Нет Первичный ключ/идентифицирующий 
столбец (щелкните правой кнопкой 
мыши на столбце РеодасЕ ТО и 
выберите в контекстном меню 56+ 
Ргитагу Кеу (Установить первич- 
ный ключ), затем в окне Соутп 
Ргорег#е$ (Свойства столбца) рас- 
кройте узел ету ЗресйсаНоп$ 
(Идентификация) и установите свойство 
(15 ТаерЕ1 у) в уез (Да)). 

Мапе пуагсрах (100) Нет А 

Резсг1рЕ1оп  пуагсБахг (500) Нет — 

Сабедоху пуагсрах (50) Нет р 


Рг1се Чес1та1 (16, 2) Нет — 
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После добавления этих столбцов окно схема таблицы в \У1зиа] Эва ю будет 
выглядеть так, как показано на рис. 4.8. 


ЧвоТаЫе1; ТаЫЕ. псе.Зрог5бфоге" 
Совутля Мате Оаа Тере аНох Е 


Е нЕ 


пагсНаг30 
Резсиреси иуагеНан5 9? 
Сакецойь НыЕгсИ ая 50 
Висе Зесниай В, 2} 


Рис. 4.8. Спецификация столбцов таблицы рходисез 


Сохраните новую таблицу (нажав <С\!+$>) под именем Ркодисез. Для проверки, 
что все работает правильно, добавим некоторые тестовые данные. Переключитесь на 
редактор табличных данных (в окне Зегуег Ехрогег щелкните правой кнопкой мыши 
на таблице РЕодисез и выберите в контекстном меню пункт ЭВо\м ТаЫе Оаа (Показать 
данные таблицы)} и введите некоторые тестовые данные, как показано на рис. 4.9. 


Ргофисвя биеги пов. бромебтоге} 
Ресдчс НО — Мате Весснряси Сатецеге Рисе 

. ‚ Кауак А Бозе ОЕ СИЕ резси еабеерай: — 27500 
еасвЕЕ Ресесиее зла ФазиопаЫе Уиаегерой= — 4835 
ЭсссЕГ а} НЕБ-арргомей зе зп мени ЗСССЕР 18.55 
ЭН рад ВаРап3 усог Зебсайе НЕ а 1ед= Зоссег 38 
Заз На’-раскед 35,003 -сеаё обасНыии Фоссег 8958 0а 
Тк сар Ттпргсте усе Бгавл еЯсепсу Ву 75% ПРЕ 16,00 
СонсажеЯ Биттег ЗескеНу Фнйгас усиг срронейй СВЕз 458 
Ныглаи сНез5 Бозе д Рая данле Рог Не ло одела Раглй,! СВЕ 7500 

} Ввиа-Бас Кило Зоч-рнией, батона задел Снесз 20а 

.* мые АЕ д Аа 


Рис. 4.9. Ввод тестовых данных в таблицу Ркодас® 5 


Обратите внимание, что при вводе данных столбец РходасеТР должен оставаться 
пустым — зто идентифицирующий столбец, поэтому ЗОГ. Зегуег заполняет его значе- 
ниями автоматически. 


Настройка ИМО ю $01 


Во избежание необходимости написания запросов и хранимых процедур ЗСТ, вруч- 
ную, давайте настроим и воспользуемся ММО ® ЗОГ. Сущность предметной области 
уже определена как класс С# (Рходис+}; теперь ее можно отобразить на соответствую- 
щую таблицу базы данных, добавив несколько новых атрибутов. 

Первым делом, добавьте ссылку на сборку Зузеет.Рафа.Т1па.я11 из проекта 
Рота1пМоде1 (в этой сборке находится реализация МЛ№О №0 ЗОГ. — вы найдете ее на 
вкладке .МЕТ диалогового окна АДА Вегегепсе (Добавить ссылку)), после чего обновите 
РГОоаисЕ следующим образом: 
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[Табе (Мате = "РкодисЕ$") ] 
риуЮ11с с1азз Рко@исЕ 
{ 
[Со] лир (ТзРезпагуКеу = гие, ТзПЮСепегавей = &гие, Ацкобупс=Аи®обупс.ОпТпзег®) ] 
рую11с 1пЕ Рко@осЕТР { дее; зеф; } 
[Сота] риб11с зЕх1пд Маме { дес; зеё; } 
[Сота] рор11с зЕт1па Резстаре1оп { деё; зе®; } 
[Со1атр] руб11с Яесипа1 Рх1се { дее; зес; } 


[Со1атп] риуб11с зЕк1п9а Сафедоку { деф; зеЕ; } 
} 


Это все, что необходимо МО 10 ЗОГ. для отображения класса С# на таблицу базы 
данных и ее строки (и наоборот). 


Совет. Здесь потребуется указать явное имя таблицы, потому что оно не соответствует имени 


класса ("РХодасе" != "Ргоаосез"). Однако это не нужно делать для столбцов и свойств, 
так как их имена совпадают. 


Создание реального репозитория 


Теперь, когда 1ЛМО 0 ЗОГ почти настроен, совсем нетрудно построить новую реали- 
зацию ТРгодасе5Веро$1®огу, которая подключится к реальной базе данных. Добавьте 
новый класс 591РгодиссВеро$1еогу в папку /Сопсгефе проекта Рота1пМоде1: 

папезрасе Ропа1пМоае1 .Сопскефе 

{ 


рую11с с1аз5 591РкодасЕ5Веро51Еоку : ТРкодасЕ5Вероз1току 
| рх1уафе Таб1е<Ргоаис®> ргодисЕзТар1е; 
рую11с 5а1Ркодосе5Веро$1Еоту (5Е+1п3 соппесЕ1оп5Ек1па) 
| ркодосезТаю1е = (пез РафаСопеех® (соппесЕ1оп5Ег30а}} .СеЕтар1е<Ргодис®> (}; 
Е ТОцекуа1е<РгодисЕ> Ргобасе5 
ое { хебогп ргодисЕезТаю1е; } 
} 


} 


Конструктор зтого класса принимает в своем аргументе строку соединения и исполь- 
зует ее для настройки РрасаСопеехе из ММО №0 $501. Это позволит раскрыть таблицу 
Ргодисе5 как интерфейс Тоцегуаю1е<Рхо@ис®>, который обеспечит всеми необходимы- 
ми средствами формирования и выполнения запросов. Любые запросы 1ЛМ№О, которые бу- 
дут выполняться отноглении этого объекта, “за кулисами” превращаются в запросы ЭОГ.. 

Теперь давайте подключим реальный репозиторий на основе ЗОГ, к приложению 
АЗРМЕТ МУС. Вернитесь к проекту МерОт и установите ссылку РХОЧиСсЕ5Сопехо11етх на 
За1РходисеВероз1еогу вместо ЕаКеРходос®зВероз$1Еогу, следующим образом обно- 
вив конструктор Реодис®Сопего11ет: 


рую11с РгодисЕ$Сопеко1 Тег () 
{ 


//Временно жестко закодированная строка соединения - до установки контейнера ТоС 
зЕ:1п9 соппбЕкара = @"Зекуек=. ;ДафаБазе=брохЕз5®оге;ТкизЕе@ Соппес1от=уез;"; 
ргобасЕВероз1фокгу = пем $91РгодисЕ:Кероз1огу (соппбЕг1па); 

} 
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На заметку! Строка соединения должна быть приведена в соответствие с используемой средой разра- 
ботки. Например, если ПК разработки установлена система ЗС Зегуег Ехргезз, со стандартным име- 
нем экземпляра ЗОЪЕХРВЕ$ $, фрагмент 5ехуег=. потребуется заменить фрагментом З5егуег= 
. \ ЗОБЕХРВЕЗ. Точно так же, если вместо аутентификации \/пдо\з применяется аутентифика- 
ция ЗСЕ Зегуег, необходимо изменить Ткеизфе@ СоппесЕ1оп=уез на 019=ИмяПользователя; 
Риа=Пароль. Символ @ перед строковым литералом сообщает компилятору С#, что обратные 
слэши не должны интерпретироваться как управляющие последовательности. 


Проверьге внесенные изменения, запустив проект. Теперь должен выводиться спи- 
сок товаров из базы данных ЗСТ, как показано на рис. 4.10. 


: Зпесег ВаН __ 


Рис. 4.10. Контроллер РЕодасеСопего11ех 
визуализирует данные из базы ЗО Зегиег 


Как видите, ММО о ЗОГ. существенно упрощает получение строго типизированных 
объектов .МЕТ из базы данных. Это не мешает применять традиционные хранимые 
процедуры для выполнения специфических запросов к базе данных, но это означает 
что вы не обязаны их писать (или любой другой низкоуровневый код 501, в результате 
экономя массу времени. 


Настройка инверсии управления 


Прежде чем углубиться далыше в приложение, и перед тем, как приступить к авто- 
матизированному тестированию, имеет смысл настроить инфраструктуру инверсии 
управления (оС). Это позволит автоматически разрешить зависимости между компо- 
нентами (например, зависимость РходисеСопехо11ех от ТРЕодас& зВероз16оху), под- 
держивая слабо связанную архитектуру и облегчая модульное тестирование. В тлаве 3 
были изложены теоретические аспекты ПОС, а теперь все это можно применить на прак- 
тике. В рассматриваемом примере будет использоваться популярный контейнер 1оС с 
открытым исходным кодом под названием СазИе УЙпазог, который понадобится скон- 
фигурировать с помощью нескольких настроек в меь .сопЕ1 9, а также путем добавле- 
ния некоторого кода в файл С1оЪа1.азах.сз. 

Вспомните, что компонентом 1оС может быть любой выбранный объект или тип 
„МЕТ. Все созданные в примере контроллеры и репозитории станут компонентами С. 
Всякий раз, котда создается экземпляр компонента, контейнер ГоС разрешает его за- 
висимости автоматически. Таким образом, если контроллер зависит от репозитория — 
возможно, требуя экземпляра в виде параметра конструктора — контейнер оС предос- 
тавит подходящий экземпляр. Просмотрев код, вы сами убедитесь, что все довольно 
просто. Если это еще не сделано, загрузите последнюю версию Сазйе УЯпазог, доступ- 
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ную по адресу зи. саз1ерхо]есЕ.ога/саз®1е/аокп1оа@. В&т19. Программа установ- 
ки зарегистрирует нужные ОИ.-библиотеки в глобальном кзше сборок (Софа! АззетЫЫу 
Сасре — САС). Добавьте в проект МеБОтТ ссылки на следующие три сборки, которые на- 
ходятся на вкладке .МЕТ диалогового окна АДа ВНегегепсе: 


® Сазйе.Соге Юг Мсгозой „МЕТ ЕгатехоК 2.0 
® СазИе.МусгоКегпе! юг Мюгозой МЕТ Егате\зогК 2.0 
® СазИеУЛпазог Юг Мсгозой МЕТ ЕгатехмогК 2.0 


Это обеспечит проекту Мет доступ к типу И1пазогСопфа1тек. 


На заметку! Если сразу же после установки сборки СазЕ1е в окне Ада Ветегепсе не появились, 
закройте и повторно откройте решение. Это заставит Мзиа! Зи 2008 обновить глобальный 
кэш сборок. 


Создание специальной фабрики контроллеров 


Простого добавления ссылки на сборку СазЕ1е.И1пазог далеко не достаточно. Сборку 
нужно подключить к конвейеру АЗРМЕТ МУС. После этого АЗРМЕТ МУС перестанет соз- 
давать классы контроллеров непосредственно, а будет запраптивать их у контейнера 1оС. 
Это позволит контейнеру 1оС разрешать любые зависимости, которые могут существовать 
у контроллера. Для этого понадобится создать специальную фабрику контроллеров (с по- 
мощью таких фабрик МУС ЕгатеуогК создает экземпляры классов контроллеров), унасле- 
довав ее от встроенного в АЗРМЕТ МУС класса РеЁал1Сопего11ехГасфогу. Создайте но- 
вый класс в корневой папке проекта ИеБоТ и назовите его И\пазокСопеко11ехЕКасфсоку: 


рур11с с1аз5$ ИМ1пазогСопего11егКасбоку : БеЕааТЕСопего1егКасфоку 
{ 

И1рпазогСопсалпег сорба1пег; 
// Конструктор: 
// 1. Устанавливает новый контейнер ТоС. 
// 2. Регистрирует все компоненты, специфицированные в меь.сопЕ1а. 
// 3. Регистрирует все типы контроллеров в качестве компонентов. 
риб11с И1идзокСойп®го11егКас®оху () 
{ 

// Создать экземпляр контейнера, взяв конфигурацию из мер. сопЁ1а 

сопразпег = пем И1пазогСорба1тек ( 

пем Хи1Тпфтегргетег (пем СопЁ1аВезойгсе ("сазт1е") )} 
); 
// Зарегистрировать все типы контроллеров как Ткапзлете 
уаг сопегоТ1екгТурез = Еком ® 1п Аззепю?Ъу. се ЕхесиЕ1тоАззепю Ту () .СеЕТурез () 
упеке ФуреоЕ (ТСопЕго11ет) .Т5Азз1лараю1еЕком (®) 
зе1есё {; 
Гогеаср (Туре Е 1п сопехоекТурез) 
сопра1пег.АдаСопропеп 1 ЕР 1 Еезфу1е (©.Ко11Мапе, &, 
Т1Еезфу1еТуре .Тгапь1еп®); 
} 
// Конструирует экземпляр контейнера, 
// необходимого для обслуживания каждого запроса 
ргосесфеЯя оуегг1ае ТСопеко11ек сееСопегоТек1Ттзфарсе (Туре сопего11етТуре) 
{ 
теракт (ТСорего11ег) сопба1пег .Везо1уе (сопего11егТуре); 


} 


9 На момент выхода в свет русскоязычного издания этой книги последней версией была 2.0. 
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Обратите внимание на необходимость добавления нескольких операторов из1пд, 
чтобы компиляция прошла успешно. Как видно из самого кода, компоненты регистри- 
руются в двух местах. 


® Раздел файла мер .сопЕЁ1а под названием сазё1е. 


® Несколько строк кода, которые сканируют сборку, чтобы найти и зарегистриро- 
вать типы, реализующие ТСопего1 1ех (т.е. все классы контроллеров). Это избавля- 
ет от необходимости перечислять их вручную в файле меЪ. сопЕ1 с. Контроллеры 
регистрируются с типом 11Ее5$ у1еТуре .Ткапз1епе, поэтому по каждому запро- 
су будет получен новый экземпляр контроллера, что соответствует стандартному 
поведению АЗРМЕТ МУС. 


В файле меь. сопЕ19 пока нет раздела по имени саз®1е, поэтому давайте добавим 
его. Откройте файл меь .сопЕ1д (находящийся в корневой папке проекта Меьот) и до- 
бавьте следующий фрагмент к его узлу сопЕ1д3есе+опв: 


<сопЕ1абесЕ1опз> 
<зесЕ1оп паше="саз1е" 
фуре="Саз1е .И1и@зох .СопЕ1дига1оп .Арррота1т.СазЕ1ебес®1опНапа1ехг, 
СазЕ1е.ИМ1пазог" /> 


<!-- ... узлы всех прочих разделов остаются неизменными ... --> 
</сопЕ1табесЕ1о05> 


Затем внутри узла <сопЕ1дига1опт> добавьте узел <саз®1е>: 
<сопЕ1дагаЕ1оп> 
<!-- ебс --> 
<сазЕ1е> 
<сопропеп®$> 
</сотропепез> 
</сазЕ1е> 
<зузеет.мер> 
<и-=еес. ==> 


Узел <саз®1е> можно поместить непосредственно перед <зузфеш.меь>. Наконец, 
проинструктируйте АЗРМЕТ МУС о необходимости использования новой фабрики кон- 
троллеров, вызвав Зе Сопего11егРГассогу(} внутри обработчика Арр11саЕ1оп_З$агё 
в СТораф.азах.сз: 


рготессеа уо1а Арр11са1оп З$ак® () 
{ 

Вед1зегВойфез (ВосфеТар1е .Воцеез) ; 

Солфго11егВи114ек .Сихгепь. беСопего]ЛекРасфогу (лем ИЧпЯзогСолего]1екЕас®огу ()); 
} 


В этот момент неплохо бы проверить, все ли по-прежнему работает. Новый контей- 
нер 1оС должен быть в состоянии разрешать РкодасЕСопего11ех, когда АЗРМЕТ МУС 
запросит его, так что приложение должно работать, как будто бы ничего не менялось. 


Использование контейнера инверсии управления 


Контейнер 10С применяется для исключения жестко закодированных зависимостей 
между компонентами. На данном зтапе необходимо избавиться от имеющейся жестко 
закодированной зависимости РкодисЕзСопего11ег от За1РгодосьВероз1®оку (что, в 
свою очередь, означает избавление от жестко закодированной строки соединения, ко- 
торая будет сконфигурирована где-то в другом месте). Преимущества такого решения 
очень скоро станут очевидными. 
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Когда контейнер 1оС создает объект (те. класс контроллера), он проверяет список па- 
раметров его конструктора (те. зависимости) и пытается применить подходящий объ- 
ект для каждого из них. Таким образом, добавьте к конструктору РкодисеСопеко11етх 
новый параметр, как показано ниже: 


раБ11с сфазз РкодосЕзСореко Тег : Сопбго11ек 


{ 


} 


рг1уаЕе ТРгодисезВеро$1еогу ргодасЕзВероз16огу; 
рчЬ11с Ргодасе8СопЕго11ег (ТРгочасЕ=Кероз1Фогу ргодисЕ-Вероз1Фогу) 
{ 
+513 .ргоаисЕВероз1Еогу = ргодасеКероз1окгку; 
} 
раБ11с У1еиВезо1® 115% ()} 
{ 


гебаки У1ем (ргодисЕзВероз1Еоку.Рко@дисе$.То11 56 ()); 


В этом случае контейнер оС определит, что РгодисеСопЕко11ег зависит от 
ТРгодисЕзВероз1огу. При создании экземпляра РгодасЕ $СопЕго11ет теперь не будет 
никакой жесткой связи с каким-то конкретным репозиторием. Чем это выгодно? 


® Это начальная точка для модульного тестирования. В данном случае это означает, что 


автоматизированных тесты работают с собственной имитированной, а не с реальной 
базой данных, что намного ускоряет тестирование и делает его более гибким. 


Это позволит приблизиться к разделению ответственности и достичь большей 
ясности. Интерфейс между двумя частями приложения (РкодасЕ Сореко1Тек и 
репозиторием) теперь становится очевидным фактом, а не просто существует в 
вашем воображении. 


Вы защищаете кодовую базу от возможной будущей путаницы или вмешательства 
других разработчиков. Теперь намного менее вероятно, что кто-то не поймет, почему 
контроллер отделен от репозитория, и не объединит их в одно неподатливое целое. 


Вы можете легко присоединить любой другой интерфейс ГРкодисе5Вероз1Еоку 
(например, для работы с другой базой данных или технологией ОВМ}, не затраги- 
вая скомпилированной сборки. Это очень удобно в случае совместного использо- 
вания программных компонентов в разных проектах внутри компании. 


Звучит достаточно убедительно, но действительно ли все зто работает, как было опи- 
сано? Попробуйте запустить приложение, и вы получите сообщение об оптибке, пока- 
занное на рис. 4.11. 


| егуег Екгог № ‘/“ АррНсаной. 


и 
} Сап\ сгеме сотроленё 'Ргодисесоггойег" аз # раз Череп4епеез © Бе сайвбеа. 
РгоЧисясопегоег 15 иайто Гог ре Ройоилпа дерепдепсе:: 


5енйсе5: 
- Ротатмоде/ Ара ТРгобиссверо$йогу РСН игяз пот гертегтед, 


Чи ити 


| 


Рис. 4.11. Сообщение об ошибке Мйпд$ог, связанное с тем, что 
компонент не был зарегистрирован 
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Причина возникновения ошибки состоит в том, что ТРкодисЕзВерозлфоку пока не 
зарегистрирован в контейнере 1оС. Вернитесь к файлу меь .сорЕЁ1а и обновите раздел 
<сазЕ1е>: 


<саз©1е> 
<сотшроперез> 
<сотропепЕ 14="РгоЯзВероз1Еоку" 
зеку1се="Рота1 Моде] .АБзфгас®.ТРгобисеВероз1+оку, Бота1пМоае1" 
Еуре="Бота1пМо4е1 .Сопске&е. За1РгофасьВерозАоку, Ропа1иМоде1"> 
<рагате®егз> 
<соппес®1оп5 1 по>уоцг соппесЕ1оп зЕт1па доез Беге</соппесЕ1от$ Ег1па> 
</рагашефегз> 
</сотропепЕ> 
</сотровепе$> 
</сазЪ1е> 


Попробуйте запустить приложение теперь, и вы увидите. что все снова работа- 
ет. Репозиторий 5$91Ргодисе ВКероз1коху назначен в качестве активной реализации 
ТРкодис&е5Вероз1Еоку. Конечно, при желании ГакеРходисезВероз1еогу можно из- 
менить. Но обратите внимание, что строка соединения теперь находится в файле 
ме . сопЕ19. а не скомпилирована в двоичный файл РМ /. 


Совет. Если приложение имеет дело сразу с несколькими репозиториями, не копируйте одну и 
ту же строку соединения в каждый узел <сотропепЕ>. Взамен заставьте свойства \М/па$ог 
совместно использовать одно и то же значение. Добавьте <ргорегЕ1ез><пуСоппзЕк>ххх 
</щуСопп$х></ргорек1ез> (где ххх — строка соединения) в узел <сазЕ1е>, и затем для каж- 
дого компонента замените значение строки соединения дескриптором ссылки # {пуСопиб г}. 


Выбор стиля жизни компонента 


В СазЦе УЙпазог можно задавать стиль жизни для каждого компонента 1оС. Возможны 
следующие стили: Ткапз1епте, $1п91ефоп, РехИерВесиез*, Роо1е@ и Сизфом. Они опре- 
деляют, когда контейнер должен создавать новый экземпляр каждого объекта — компо- 
нента 1оС, и какие потоки разделяют эти экземпляры. Стилем по умолчанию является 
З1па1ебоп (одиночка), означающий существование единственного экземпляра объекта 
компонента, который доступен глобально. 

Для репозитория ЗафРкоачсе5Вероз1когу в настоящее время установлен стиль 
жизни 51п191еСоп, так что на протяжении работы приложения поддерживается един- 
ственный РасаСопеес® из ММО {о ЗОГ, который разделяется между всеми запросами. 
Пока это может показаться достаточным, потому что весь доступ до сих пор был только 
для чтения. Однако это приведет к проблемам, когда начнется редактирование данных. 
Незафиксированные изменения начнут теряться между запросами. 

Во избежание этой проблемы измените жизненный стиль ЗАтРкоаисе$Вероз1коку 
на РекмеВечаез%, обновив его регистрацию в меь. сопЕ 19: 


<сотроперЕ 19="РгоазВероз1фогу" 
зекулсе="рота1пМоде1.Абзекасе. ТРгодасе$Веро51Фогу, Ропа1пМоае1" 
туре="Рота1пМоде1 .Сопстеее .5а1Ргодисе5Вероз1®оку, БотафиМоде1" 
11езЕу1е="РегИеБВедиез "> 


ю Поскольку АЗРМЕТ МУС имеет встроенную поддержку конфигурирования строк соединения 
в узле <соппесе10п5х1п95> файла меб . сопЕ1<, ничего особенного в этом нет Чем действи- 
тельно полезна инверсия управления — так это возможностью ее применения для настрой- 
ки любого набора параметров конструктора компонента вообще без написания кода. 
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Затем зарегистрируйте модуль УИпазог РехВесиез ЕТ Еезбу1е в узле «НЕЕрМови1ез>!: 


<ВЕЕрРМоа1е5> 
<ааа паме="РегКечиез 11Еез®у1е" 
фуре="СазЕ1е .М1сгоКегпе1 .11Еезфу1е .РегИерКечиез 11 Еезу1еМоди1е, 
СазЕ1е.М1сгоКегпе1" /> 
<!-- Оставить остальные модули без изменений --> 
</БЕЕРМодо1е$> 


Если позже понадобится развернуть приложение на веб-сервере П$ 7, добавьте сле- 
дующую эквивалентную конфигурацию в узел <зузеет. мер$егуег>/<поЯи1ез> файла 
меЪ . сопЕ1 а (подробно о конфигурации П$ 7 речь пойдет в главе 14): 

<гешоуе вапе="РегВесиез (11 Ёезку1е"/> 

<ааа папше="РегВесие${11Еезфу1е" рхеСопа1Е1оп="тападедНапо1ет" 

фуре="Саз®1е .М1сгоКегпе{ .11Ёезбу1е .РехИервеаиез 11 ЁЕезЕу1еМоди1е, 
СазЕ1е.М1скоКегпе?" />\ 


Значительное уменыпение необходимого объема работы является замечательной 
особенностью контейнеров 1оС. Шаблон построения объекта рафаСопфеесь для каждого 
НТТР-запроса реализуется исключительно настройкой файла меБ. сопЕ1 д. 

Итак, работающая система на основе инверсии управления настроена. Независимо от 
количества добавляемых компонентов и зависимостей, основной механизм уже готов. 


Создание автоматизированных тестов 


Теперь, когда почти все фундаментальные части инфраструктуры готовы (структура 
решения и проекта, базовая модель предметной области и система репозиториев 110 
{0 5@Г, а также контейнер 10С), можно приступать к реальной работе по реализации 
поведения приложения и написанию для него тестов. 

В настоящее время Рходас& зСопего11ет генерирует список всех товаров, содер- 
жащихся в каталоге. Давайте усовершенствуем это: первым поведением приложения, 
которое мы будем тестировать и кодировать, будет генерация постраничного списка то- 
варов. В этом разделе вы увидите, как можно комбинировать МОпй, Мод и компонент- 
но-ориентированную архитектуру для проектирования нового поведения приложений с 
использованием модульных тестов. 


На заметку! Разработка, управляемая тестами (ТОО) — это не методика тестирования, а принцип 
проектирования (хотя и учитывающий некоторые аспекты тестирования). ТОО предполагает 
описание желаемого поведения в форме модульных тестов, которые позднее запускаются для 
проверки, удовлетворяет ли полученная реализация требованиям проекта. Создание фиксиро- 
ванного описания проектных решений, которые можно быстро проверить на следующих верси- 
ях кодовой базы, позволяет отделить проект от реализации. Название “разработка, управляе- 
мая тестами” выбрано неудачно, поскольку акцентирование внимания на тестировании вводит 
в заблуждение. Появившееся относительно недавно понятие “разработка, управляемая пове- 
дением” (Венамог-Ойуеп Везюп — ВОО) можно счесть более приемлемым, хотя его отличия от 
ТОВ (если они вообще есть) являются предметом совершенно другой дискуссии. 


Всякий раз, когда создается тест, который не проходит или не компилируется (так 
как приложение пока что не удовлетворяет его условиям), он выдвигает требование из- 
менить код приложения так, чтобы условия теста были удовлетворены. 


и Интерфейс тнеермода1е в УЙпавог служит для поддержки РегмерВечиез 11 Еезу1еМодо1е, 
так что он может перехватить событие Арр11са1оп_ЕпаВечиезе и отменить все, что было 
создано во время запроса. 
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Энтузиасты ТОР предпочитают вообще не изменять своих приложений, кроме как 
в ответ на сбойные тесты, тем самым гарантируя, что комплект тестов представляет 
полное (в разумных пределах) описание всех проектных решений. 

Если такой формальный подход к проектированию по каким-либо причинам не удов- 
летворяет. можете не применять ТОР в этой и последующих главах, не обращая внима- 
ния на врезки. Использование ТОР в АЗРМЕТ МУС обязательным не является. Однако 
эту методику стоит опробовать, чтобы увидеть, насколько она подходит к вашему про- 
цессу разработки. Следовать ей строго или не очень — выбор исключительно ваш. 


Подготовка к началу тестирования 


В дополнение к ранее созданному проекту Тез®з также понадобятся два инструмента мо- 
дульного тестирования с открытым кодом. Если это еще не сделано, загрузите и установите 
последние версии МИпй (среда с графическим интерфейсом пользователя для определения и 
прогона модульных тестов, доступная по адресу Вер: //иим. пир1е.ога/") и Мод (среда 
имитации, спроектированная специально для синтаксиса С# 3.5 и доступная по адресу ВЕЕр: // 
соде .доод1е.сош/р/точ/'3). Добавьте в проект Тез з ссылки на следующие сборки: 


® пип1Е. ЕхамемогК (из вкладки .МЕТ окна Ада Нетегепсе} 

® Зузсеш.МеЪ (из той же вкладки .МЕТ) 

® Зузсеш.Иер.АБзегасе1олз (из той же вкладки .МЕТ) 

® Зузсем. Мер .Во1Е1пц (из той же вкладки .МЕТ} 

® Зузтеп.Меь.Мус . 911 (из той же вкладки .МЕТ} 

® Моа.а11 (из вкладки Вго\м/зе (Обзор), потому что после загрузки Мод получается только файл 
сборки, который не зарегистрирован в САС). 

® Ваш проект ропа1пМоае? (из вкладки Ргоес{$ (Проекты)} 

® Ваш проект Меьот (из вкладки Ргоес$) 


Добавление первого модульного теста 


Для построения первого модульного теста создайте в проекте ТезЕз класс по имени 
Ргодисе5Сореко11екТез& $. Нервый тест будет проверять способность действия 1131 ра- 
ботать с номером страницы, переданном в качестве параметра (например, Ъ15+ (2) ), помещая 
в Моде1 только нужную страницу товаров: 

[ТезеЕ1хфоке] 


рую11с с1азз РкодасЕ5Сорско1ЛехТезез 
{ 
[Тез] 
рур11с уота 1180 Рхезепез Соггесг Раде ОЁ Ркодисез () 
{ 
// Подготовка: 5 товаров в репозитории 
ТРкодисеВероз1Фоку кероз1еоку = МоскРкодисе5Веро51Когу ( 


пем Ркодис® { Маше = "Р1" }, пем Рко@осе { Маше = "Р?" }, 
пем РкобосЕ { Маше = "РЗ" }, пем РкодиасЕе { Маше = "РА" }, 
пеи Ргоаосе { Маме = "Р5" } 


); 
РкодисЕ5Сопеко11ек сопёко11ех = пем РкоЧбисезСопеко1 Тех (хероз1оку) ; 
сопеко11ег.Раде51те = 3; // Это свойство пока не существует, но 
// обращаясь к нему, вы неявно формируете 
// требование о его существовании 
// Действие: запросить вторую страницу (размер страницы = 3) 
уаг гез\а1Е = сопеко11ек.115% (2); 


12 На момент выхода в свет русскоязычного издания этой книги последней версией была 2.5.3. 


13 На момент выхода в свет русскоязычного издания этой книги последней версией была 3.1. 


Глава 4. Реальное приложение Зро{1юе 117 


// Утверждение: проверить результаты 
Аззеке.15Мо №11 (хези1, "Р1ап'Е кепдег у1ем"); // Представление не визуализировано 
уУак ргодас®5 = гези1е.У1лемра$а.Моде1 аз 1115Е<Ргодасе>; 
Аззеге.АкеЕдоа1 (2, реодасе$.Соппе, "СоЕ мкопа пипфег оЁ рко@исЕз"); 
// Получено неверное количество товаров 

// Удостовериться, что выбраны правильные объекты 
Аззеге.АкеЕсоа1 ("Р4", рходас® $ [0] .Мапе); 
Аззете.АгеЕдоа1 ("Р5", ргодас®$ [1] .Маше); 

} 

збаЕ1с ТРЕОодисеВеров1Еогу МоскРЕОдасЕ$Вероз1Фогу (ракащз Ркобисе[] рго@з) 

{ 
// Сгенерировать реализатор ТРЕоаисЕВероз1®огу во время выполнения с помощью Моя 
уУах поскРкодисЕзВероз = пем Моа.Моск<ТРкодисе$Вероз1®огу> (); 
поскРгоаисезВеро$ .5е бар (х => х.Рко@асез) .Вебиагиз (рко9$ .-АзОцегуаю1е ()); 
хебакп посКкРкодисезВероз .ОЮ]есе; 

} 

} 


Как видите, зтот модульный тест эмулирует определенное условие репозитория, которое поддается 
осмысленному тестированию. Для создания реализатора интерфейса ТРкодисезВероз1®оху, 
который должен вести себя определенным образом (возвращая указанное множество объектов 
Рко@ис®) в Мод используется механизм генерации кода во время выполнения. Это намного 
легче, аккуратнее и быстрее, чем действительно загружать реальные строки в базу данных 501 
Зегуег для целей тестирования, и зто возможно лишь потому, что РкодосЕзСопехо11ех обра- 
щается к своему репозиторию только через абстрактный интерфейс. 


Проверка проходит ли тест 


Попробуйте скомпилировать решение. Поначалу вы получите ошибку компиляции, потому что 
Тл зе () пока не принимает никаких параметров (а вы пытаетесь вызвать 1,15% (2) ), к тому же 
еще не определено свойство РеодисезСорего11ек.Радеб1те (рис. 4.12). 


Намеренное написание кода теста, который не может быть скомпилирован (средство \ейЗепзе 
также начинает сбоить), может показаться странным, но зто — один из приемов ТОО. Ошибка 
компиляции фактически может рассматриваться как первый провал теста. Она выдвигает тре- 
бование создать некоторые новые методы и свойства {в данном случае ошибка компиляции вы- 
нуждает добавить новый параметр раде к методу 115+ () }. Дело вовсе не в том, что мы хотим 
получить ошибки компиляции, а в том, что мы хотим написать тесты первыми — даже если они 
вызовут ошибки компиляции. Некоторым такой подход не по душе, позтому они одновременно с 
написанием тестов создают заготовки методов или свойств, удовлетворяя и компилятор, и 1ЮЕ- 
среду. Как поступать вам — решайте сами. В главах, посвященных разработке Зрои$ юге, приме- 
няется “аутентичный” подход ТОБ: сначала пишется код тестов, несмотря на то, что он поначалу 
вызывает ошибки компиляции. 


Добейтесь успешной компиляции кода, добавив в класс РеодисЕСопЕхо11ех поле-член 
Радеб1те типа р1Ю11с 11%, а в метод 1$ () — параметр раде типа 11+ (измененный 
код показан сразу после врезки). Загрузите графическую среду МИпй (она устанавливается 
вместе с МИпй и, возможно, появляется в меню Пуск системы Мйпдомз), выберите в ее меню 
пункт РНе=?Ореп РгаесЕ (Файл®Открыть проект) и затем найдите скомпилированную сборку 
Тезе$ .911 (она должна располагаться в папке Решение\ Тез з\61п\рерод\). Графическая 
среда МУпй просмотрит сборку в поисках классов с атрибутом [Тез Е1хеиге] и отобразит их 
вместе с методами, помеченными [ТезЕ], в графической иерархии. Щелкните на кнопке Вип 
(Выполнить); результат можно видеть на рис. 4.13. 

Неудивительно, что тест по-прежнему не проходит: текущий контроллер РходасЕ=СопЕго11ег 
возвращает все записи из репозитория вместо лишь одной запрошенной страницы. Как объяснялось 
в главе 3, зто хороший признак: при разработке в стиле “красная полоса — зеленая полоса” сначала 
необходимо обнаружить сбой теста, а затем кодировать поведение, которое заставит тест проходить 
успешно. Это подтвердит, что тест действительно реагирует на только что написанный код. 
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Рис. 4.13. Полоса красного цвета в графической среде МИпй свидетествует 
о том, что тест не прошел 


Если это еще не сделано, обновите метод Т4з+ () класса РгодосеСопего11ех, доба- 
вив к нему параметр раде, и определите Раде51те как рою11с-член класса: 


РУБ1с сЪазз Ркодосе$Сопего1Тег : Сопеко11ек 
{ 
РЧЬ11с пе Раде$1те = 4; // Позже это будет изменено 
рге1уабе ТРкоаис®$Вероз1фоку ркодисЕзВероз1®оку; 
РАБ с Ргобасе8Сопеко Тех (ТРкодисе5Вероз1еоку ргобисьзВероз1$огу) 
{ 
{515 .ргодисе$Вероз1еоку = ргодисезВероз1кохку; 
} 
рУБ11с У1емВези 115% (106 раде) 
{ 


хегакп У1ем (ргодосЕзВеро$1$огу.Ркодис®е$.То115% ()); 


} 


Теперь можно добавить поведение постраничного вывода списка. До появления ЛМО 
зто было непростой задачей (ЗОГ, Зегуег 2005 может возвращать постраничные наборы 
данных, правда, не особо очевидным способом), а теперь это делается единственным 
злегантным оператором С#. Обновите метод 115% () следующим образом: 


раБ11с У1емВезо1 115% (106 раде) 
{ 
гебоаго Улем (ркодасЕзВероз1Еоку.Ркодисе5 
.ЗК1р ( (раде - 1) * Радеб1те) 
.Таке (Радеб1те) 
.Тот1 55 () 
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Если вы сопровождаете разработку модульными тестами, перекомпилируйте реше- 
ние и заново запустите тест в графической среде МОпй. Должна быть получена полоса 
зеленого цвета, свидетельствующая об успешном прохождении теста. 


Конфигурирование специальной схемы ЦВЕ 


Добавление параметра раде к действию 113% () было замечательно для модульного 
тестирования, но зто вызовет небольшую проблему при попытке запуска приложения 
(рис. 4.14). 
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Рис. 4.14. Возникла ошибка из-за того, что значение для параметра раде не указано 


Каким образом среда МУС сможет вызвать ваш метод 115% (), если ей не известно, 
какое значение должно передаваться в раде? Если бы параметр относился к ссылочно- 
му типу или к типу, допускающему значения пи11"\, могло быть передано просто пи11, 
однако 11$ к упомянутым типам не относится, поэтому возникает онтибка. 

В порядке эксперимента попробуйте изменить ОН, в браузере на Вер: // 
Тоса1ВозЕ: ххххх/?раде=1 или ВЕЁр: / /1оса1Во5% : ххххх/ ?раде=2 (замените ххххх 
на используемый номер порта). Вы обнаружите, что все работает — приложение мо- 
жет выбирать и отображать соответствующую страницу результатов. Причина в том, 
что когда АЗРМЕТ МУС не может найти параметр маршрутизации, соответствующий 
параметру метода-действия (в данном случае раде), предпринимается попытка исполь- 
зовать вместо него параметр строки запроса. Это механизм привязки параметров, ко- 
торый детально рассматривается в главах 9 и 11. 

Приведенные выше ОВ, выглядят довольно неуклюже, к тому же должны выпол- 
няться какие-то действия, даже когда в строке запроса параметр вообще не передается. 
Это значит, что наступил момент для редактирования конфигурации маршрутизации. 


Добавление элемента ВопЕетТаЪ1е 


Решить эту проблему отсутствующего номера раде можно, установив в конфигура- 
ции маршрутизации значение по умолчанию. Вернитесь к файлу С10Ъа1.азах. сз. уда- 
лите существующий вызов МарВоцте и замените его следующим: 


“Тип, допускающий значения по11 — это такой тип, для которого по11 является действи- 
тельным значением. В качестве примеров можно привести типы обес, з&х1па, Зузкем. 
№11ар1е<1те> и любой класс, определяемый пользователем. Экземпляры этих типов рас- 
положены в “куче” и доступны через указатель (который может быть установлен в пи11). 
Совсем иначе обстоят дела с 11%, Рабет1ие или любой структурой (зЕхис\(). Они хранятся в 
виде блока памяти в стеке, поэтому устанавливать их в п111 бессмысленно (в занимаемом 
ими пространстве памяти что-то должно находиться). 
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гоифез$ .МарБойее ( 


ра, // Назначать имя этому элементу маршрута не обязательно 
ИЯ // Соответствует корневому ОВЦ, т.е. -/ 
рем { сопЕко11ег = "Ркодасез", асЕ1фоп = "1156", раде = 1 } // настройки 


// по умолчанию 
); 
гоибез.МарВочцее ( 


11211, // Назначать имя этому элементу маршрута не обязательно 
"Раде{раде}", // Шаблон ОВ, например ^/Радеб683 
пем { сопеко11ек = "Ргодисе5", асЕ1оп = "1156"}, // Настройки по умолчанию 


рем { раде = @"\а+" } // Ограничения: раде полжно быть числовым 
); 
Что получается в результате? Это значит, что могут существовать два приемлемых 
формата ОВ!.. 


® Пустой ОВ! (корневой ОВГ, те. БЕЕр : //сайт/), который вызовет действие 1,15 () 
на контроллере Ркодисе$Сопего11ек, передав ему значение по умолчанию, рав- 
ное 1. 


® ОРГ в форме Раде{раде} (например, ВЕЕр://сайт/Раде41), где раде должно 
соответствовать регулярному выражению "\4+" . те. состоять исключительно 
из десятичных цифр. Такие запросы также отправляются методу 115% () класса 
РкодасеСопско1 Тег с передачей значения раде, извлеченного из ОВ!.. 


Теперь попробуйте снова запустить приложение. Вы должны увидеть нечто вроде 
показанного на рис. 4.15. 
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Рис. 4.15. Логика разбиения на страницы обеспечивает 
выбор и отображение только первых четырех товаров 


15 В эгом коде оно предварено символом @, который сообщает компилятору С# отом, что обрал- 
ный слэш не должен интерпретироваться как начало управляющей последовательности. 
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Отлично! Теперь отображается только первая страница товаров, а для просмотра дру- 
гих страниц можно добавлять их номера к ЧМ, (например, ВЕЕр://1оса1ноз+Е:рокЕ/ 
Раде2). 


Отображение ссылок на страницы 


Возможность ввода ОБТ, вроде /Раде? или /Раде59 просто таки замечательна, но 
вы — единственный, кто об этом знает. Посетители могут и не догадаться вводить такие 
ВЕ. Очевидно, что внизу каждой страницы списка товаров необходимо визуализиро- 
вать ссылки на другие страницы, позволяющие посетителям осуществлять навигацию 
по страницам. 

Для этой цели потребуется реализовать многократно используемый вспомогатель- 
ный метод НТМЕ (подобный упоминавитимся в главе 2 методам НЕп1.ТехеВох() и 
НЕ .ВестиРогм ()), который сгенерирует НТМГ-разметку для ссылок на страницы. 
Когда необходим очень простой вывод, разработчики приложений АЗРМЕТ МУС вме- 
сто серверных элементов управления в стиле \еБЕогиз обычно применяют эти легко- 
весные вспомогательные методы, потому что они просты, прямолинейны и очень легко 


тестируются. 
Все это потребует выполнения нескольких шагов. 


1. Тестирование. Если вы пишете модульные тесты, то всегда пишите их первыми! 
И АР-интерфейс, и вывод вспомогательного метода НТМЕ должны определяться 
с использованием модульных тестов. 


2. Реализация вспомогательного метода НТМГ, (для удовлетворения требований тес- 
тового кода). 


3. Подключение вспомогательного метода НТМГ, (модификация кода РкодисЕ$СолЕто1 Лех 
с целью передачи представлению информации о номере страницы и соответст- 


вующего обновления представления посредством нового вспомогательного метода 
НТМИ. 


о я а 
Тестирование: проектирование вспомогвтельного метода Раде 1окз 


Вспомогательный метод РадеЪ1пКз проектируется кодированием нескольких тес- 
тов. Во-первых, в соответствии с соглашениями АЗР.МЕТ МУС, зто должен быть расши- 
ряющий метод класса НЕм1Не1рег (чтобы представления могли запускать его вызовом 
<%= НЕм1.Раде1окз(...) %>). Во-вторых, на основе номера текущей страницы, общего ко- 
личества страниц и функции, вычисляющей ЦВЕ для заданной страницы (например, лямбда-мето- 
да) он должен вернуть некоторую НТМЕ-разметку, содержащую ссылки (т.е. дескрипторы <а>) на 
все страницы, применяя некоторый специальный класс С5$ для выделения текущей страницы. 


Создайте в проекте ТезЕз новый класс РадеНе1ретТез{з и выразите проект в форме модуль- 
ных тестов: 


[ТезЕЕ1х{итге] 

руф11с с1азз РадлпаНе1регТезе$ 

{ 
[ТезЕ] 
руЮ11с уо1а Раде Локз Мебноа_ ЕхЕепаз Ни] Не1рег () 
{ 


Нел1Не]рехг №1 = пи11; 
Ь6та1 .Раче!1икз (0, 0, пи11); 
} 
[Тез] 
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рую11с уоза Раде ликз Ргоаисез Апспог Тадз() 
{ 
// Первым параметром будет индекс текущей страницы 
// Вторым параметром — общее количество страниц 
// Третьим параметром — лямбда-метод для отображения номера страницы на ее ОВ 
зЕк1па 110К$ = ((НЫне1рег) пи11) .Раде1оКз (2, 3, 1 => "Раде" + 1); 
// Дескрипторы должны быть сформатированы следующим образом 
АззегЕ.АгеЕдиа1 (@"<а ргеЕ=""Раде1"">1</а> 
<а с1азз=""зе1есфеа"" ьгеЕ=""Раде2"">2</а> 
<а ргеЁЕ=""Раде3"">3</а> 
", 1310К5); 
} 
} 


Обратите внимание, что первый тест даже не содержит вызова АззегЕ (). Он проверяет, расши- 
ряетли РадетзоКз () класс НЕт1Не1рек, просто не давая компилироваться, если это условие 
не удовлетворено. Разумеется, зто означает, что тесты пока компилироваться не будут. 

Также следует отметить, что второй тест проверяет вывод вспомогательного метода с исполь- 
зованием строкового литерала, который содержит как символы новой строки, так и символы 
двойных кавычек. Компилятор С# не будет испытывать проблем с такими многострочными лите- 
ралами, если вы соблюдаете правила форматирования: предваряете строку символом & и затем 
повторяете двойные кавычки. Избегайте непреднамеренного добавления лишних пробелов в ко- 
нец многострочного литерала. 


Реализуйте вспомогательный метод НТМГ, Раде 1пКз, создав в проекте МероТ но- 
вую палку по имени НЕп1Не1регз. Добавьте новый статический класс под названием 
Расд1оане1рекгз: 


рапезрасе Иеьот.нНет1Не]1регз 
{ 
риЮ11с зЕаЕ1с с1аз5 РадлоанНе1рег$ 
{ 
рую11с збае1фс зег1од Раче1окз (613 НЕш1Не1рек БЁи1, 146 сигхепфРасе, 
105 соса1Радез, Еипс<10е, $Ег1па> раде0г1) 


5Ег1п9Ви114ег хези1е = пем ЗЕг1ооВи11аег(); 
Гог (10 1 = 1; 1 <= Еоба1Радез; 1++) 
{ 
ТадВи11аетг Бад = пем ТадВи114ет("а"}; // Конструирует дескриптор <а> 
ад .МегоеАЕЕгаЮиее ("ВгеЁ", раде0к1 (1)); 
Еач.ТипегНЕ] = 1.ТобЕг1оа(); 
ТЕ (1 == сиггепЕРасде) 
Еад.АЧЯаС$С1а$$ ("зе1есёеа")}; 
гези1е.Аррепа|1те (фач.ТоЗЕг1поа ()}}; 
} 
гебиги гезо1е.ТобЕг1по (}; 


} 


Совет. В специальных вспомогательных методах НТМЕ фрагменты НТМЕ-разметки можно строить 
с помощью любой предпочитаемой вами техники: в конце концов, НТМЕ-разметка — зто про- 
сто строка. Например, можно воспользоваться методом зЕх1па.АррепаЕРогтае (). Однако 
в приведенном выше коде демонстрируется возможность применения служебного класса 
ТадчВи11аек из АЗРМЕТ М\С, который внутри АЗРМЕТ МУС используется при конструирова- 
нии вывода большинства встроенных вспомогательных методов НТМЕ. 
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Как специфицировано тестом, этот метод Раде 1пкКз () генерирует НТМЕ-разметку 
для множества ссылок на страницы, с учетом известного номера текущей страницы, 
общего количества страниц и функции, которая создает ОВ! для каждой страницы. Это 
расширяющий метод класса НЕт1Не1рег (обратите внимание на ключевое слово +615 
в сигнатуре метода), из чего следует, что его можно очень просто вызывать из шаблона 
представления: 


<%= НЕи1.Радер1оК$ (2, 3, 1 => Ог1.АсСЕтоп ("ТА зе", пем { раде = 1 })) %> 


С учетом текущей конфигурации маршрутизации этот вызов генерирует следующую 
НТМЕ-разметку: 
<а ВгеЕ="/">1</а> 


<а с1азз="зе1есфеа" ргеЕ="/Раде2?">2</а> 
<а №геЕ="/Раде3">3</а> 


Обратите внимание на соблюдение заданных правил маршрутизации и настроек по 
умолчанию: ЦВЕ, сгенерированный для страницы 1, будет выглядеть просто как / (а не 
/Раде1, что тоже работает, но не так удобно). И если приложение развернуто в вирту- 
альном каталоге, то От] .АсЕ1оп() автоматически позаботится о включении в ОВ!. пути 
к этому виртуальному каталогу. 


Доступ к вспомогательному методу НТМЕ 
из всех страниц представления 


Вспомните, что расширяющие методы доступны только после ссылки на содер- 
жащее их пространство имен с помощью оператора из1па в файле кода С# или объ- 
явления <%@ ТирогЕ ... %> в шаблоне представления АЗРХ. Поэтому, чтобы сделать 
Раде 1окКз () доступным в представлении 115+.азрх, можно было бы добавить следую- 
щее объявление в начало файла 115% .а5рх: 


<%$@ ТирогЕ Матезрасе="Иерот . нем1не1регз" %> 


Но вместо копирования и вставки одного и того же объявления во все представления 
А$РХ, использующие РадеГ1 кз (), гораздо эффективнее зарегистрировать простран- 
ство имен Иерот.НЕм1Не1регз глобально. Откройте файл иеЪ. сопЕ1 с и найдите узел 
пашезрасез внутри зузеет.иеб/радез. Добавьте в конец списка пространство имен 
вспомогательных методов НТМ!Г: 


<папезрасез> 
<ада папезрасе="Зузеет.Меь .Мус" /> 
<аЧа патезрасе="бузфет.Иер.Мус.Азах"/> 


.. ит.д. . 
<а@а патезрасе="Меьот .НЕт1Не1регз"/> 
</папезрасез> 
Теперь вызов <%= НЕт1 .Радеь10кз(...) %> может использоваться в любом шаблоне 


представления МУС. 


Снабжение представления номером страницы 


Может показаться, что всеготово для помещения вызова <5= НЕ. Рае 1пКк$(...) %> 
В 136 .азрх, но на самом деле в данный момент у представления нет никакой возмож- 
ности узнать, какой номер страницы отображается, и сколько вообще имеется страниц. 
Поэтому контроллер придется расширить, чтобы он включал дополнительную инфор- 
мацию в \У1емрака. 
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Тестирование: номера и счетчики страниц 


Контроллер РеодисЕСопеко11ег уже заполняет специальный объект Моае1 содержимым 
ТЕпомегаю1е<РгкодисЕ>. С помощью словаря У1емРа+фа он может передать также и другую 
информацию представлению. 


Предположим, что контроллер должен заполнить У1еирака ["СихгепЕРаде"] и 
У1еирака ["Тофа1Радез"] соответствующими значениями 1п+. Это можно выразить, открыв 
файл РеодисЕзСопЕко11екТезьз. сз (в проекте ТезЕз) и обновив фазу утверждений теста 
ТфзЕ Ргезепез СоггесЕ Раде ОЁ Ргоаист$ (): 


// Утверждение: проверить результаты 
Аззехке. Т5Мое 11 (тезо1, "р1адп’Е хепаег у1ем"); // Представление не визуализировано 
уаг ргодосе$ = геза1.\У1еирафа.Мо@е1 аз 1113Е<Рко@асф>; 
Аз5еге.АгеЕчиа1 (2, ргодасЕе$.Соппе, "боЕ ихопд пипъег оЁ ргодисЕ5") ; 
// Получено неверное количество товаров 
Аззеге.АгеЕаиа1 (2, (1пе)геза1е.Улемрака["СагхепЕРасе"], "Игопд раде папБег"); 
// Неверный номер страницы 
Аззеке.АгеЕаиа1(2, (1п%)гези1.Уземрака["Тоба1Радез"], "Игопда раде соипе"); 
// Неверное количество страниц 
// Удостовериться, что выбраны правильные объекты 
Аззеке.АтеЕсоа1 ("Р4", рго@асе$[0].Мапте); 
Аззеге.АгеЕаса1 ("Р5", ргодас%$[1].Мапе); 


Очевидно, что этот тест сейчас даст сбой, потому что У1емрафа["СиггепЕРаде"] и 
\У1емРафка ["Тофа1Радез"] пока не заполнены данными. 


Вернитесь к методу 113% () класса Реодисе зСопЕго11ег и обновите его для переда- 
чи информации о номере страницы через словарь У1емРака: 


риЮ11с У1емВези1е 115 (106 раде) 
{ 
11 папргоаисез = ргодисезВеро$3®оку.РгоЧис®$ .Соипе(); 
У1лемрафа["Тофа1Радез"] = (3пе)МаеЬ.Се111л9 ( (аобБ1е) пипРхо@асе$ / Радеб12те); 
\У1екрафа["СиггепЕРаде"] = раде; 
хеЕиго \У1ем (ргодасЕ5Веро$1Еогу.Ргодисе$ 
.ЭК1р ( (раде - 1) * Радеб1те) 
.ТаКе (Раде$1те} 
.Тот156 (} 


} 


Это обеспечит прохождение модульного теста, а также означает, что теперь можно 
включить НЕт1 .Раде11пкз () в представление 115% .азрх: 


<азр:СопЕепЕ СопбепЕР1асеНо1аегТр="МазпСопееп®" гипаё="зекуег"> 
<% ЕогеасВ (уаг ргодис®е лип Моае1) { %> 
<алу с1азз="16ет"> 
<в3><%= ргодисЕ.Маше %></63> 
<%= рго@асе .резск1резоп %> 
<р4><%= ргодасе.Рхг1се.То5ег1иа ("с") $%$></64> 
</а1у> 
<% } $%> 
<@лу с1тазз="радег"> 
Раде: 
<$= НЕ. Раде! пкз ( (10) Улемрафа ["СоггепЕРаде"], (1пе)Улемрафа["Тофа1Радез"], 
х => Чг1.АсеТоп ("1Т156", пем { раде =х })) $> 
</алу> 
</азр:СопепЕ> 
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Совет. Если средство еШЗепзе не распознает новый расширяющий метод РачеГ1пКз на 
Нет, значит, вы забыли зарегистрировать пространство имен ет. НЕ] Нне1регз в фай- 


ле иер . сопЕЁ1 с. Вернитесь к разделу “Доступ к вспомогательному методу НТМЕ из всех стра- 
ниц представления”. 


Проверьте приложение теперь. Вы увидите работающие ссылки на страницы, как 
показано на рис. 4.16. 


Е Бик /ПосотоЕ 52 ЕРасде - Киетле Ехруотег 


18; Нари Яосао2Е5295]Раце3З ях: 


зезеат - ыы еее гьсозени зело 


: Ваше Кше 


Не Сов -реней. Фанопй- оные Кн 


1 
| 
$ $1,200.00 | 
И 


Рис. 4.16. Ссылки на страницы 


На заметку! Столько работы — и совершенно не впечатляющий результат. Если ранее вам приходи- 
лось работать с АЗРМЕТ, то наверняка возник вопрос: почему получения всего лишь списка, раз- 
битого на страницы, понадобилось проделать такой объем работы? Ведь стандартный злемент 
управления АЗРМЕТ Ск19У1ем может делать это без дополнительных усилий? Однако то, что 
получено здесь, несколько отличается. Во-первых, вы строите это приложение на основе про- 
думанной архитектуры, которая включает правильное разделение ответственности. В отличие 
от простейшего применения элемента бг19У1ем, приложение Зрой5Юге не привязывается на- 
прямую к схеме базы данных — вы обращаетесь к данным через абстрактный интерфейс репо- 
зитория. Во-вторых, вы создали модульные тесты, которые и определяют, и проверяют поведе- 
ние приложения (с Сх1А\1еч, который тесно связанн с базой данных, это было невозможно). 
И, наконец, имейте в виду, что большинство созданного до сих пор представляет собой много- 
кратно используемую инфраструктуру (например, вспомогательный метод, Расе 1пКз и кон- 
тейнер юС). Добавление нового (отличающегося) постраничного списка теперь не потребует ни 
затрат времени, ни написания кода. В следующей главе разработка пойдет намного быстрее. 


Стилизация 


До сих пор основное внимание уделялось инфраструктуре, а не графическому ди- 
зайну. Сейчас приложение выглядит предельно сырым. Даже несмотря на то, что кни- 
га не посвящена стилям С5$ или веб-дизайну, бедность внешнего вида приложения 
ЗрогёЗоге значительно проигрывает основательности его проектной структуры, поэто- 
му давайте возьмемся за кисти! 

Обратимся к классической компоновке из двух столбцов с заголовком, т.е. чему-то 
вроде показанного на рис. 4.17. 

Согласно концепции мастер-страниц и страниц содержимого АЗР.МЕТ, заголовок и 
боковая панель должны определяться на мастер-странице, а основное тело будет пред- 
ставлено элементом СопеепЕР1асеНо1аег по имени Ма1пСопЕеп+. 
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Ноте. * РГобис 1 
* бон’ * РгодисЕ 2 
* Зоссег` ... ИТД. = 
* Зайтд ({ тело ) 

сне итд: 


Рис. 4.17. Черновой набросок компоновки сайта 


Определение компоновки в мастер-странице 


Реализовать такую компоновку несложно. Для этого понадобится обновить шаблон 
мастер-страницы /\У1еи5/5ВагеЯ/51+Ее .Мазеег, как показано ниже: 


<%@ Мазеег Гапотаде="С#" Тобег1Ез="бузеешт.Меф.Мус.У1еиМаз®егРаде" % 
<!РОСТУРЕ Бет1 РОВЬТС "-//МЗС//РТО ХНТМГ, 1.0 ЗЕхзсЕ//ЕМ" 
"ВЕЕр: //мим.и3 -оха/ТВ/хВ 11 /ОТО/хЬЕи11-$6:1с6.а6а"> 
<Веи1 хи13="ВЕЕр://мим. м3 .0х9/1999/хнВЕт1"> 
<ВеаА гипае="зехуег"> 
<Е1Е1е><азр:СопеерпЕР1асеНо1дег ТР="тТ1&1еСопеепе" гипаё="зегуег" /></&11е> 
</веад> 
<фоау> 
<а1у 1а="Беаег"> 
<а1у с1азз="631е">бРОВТ$ ЗТОВЕ</Я3 > 
</а1х> 
<@93у 14="саведог1ез"> 
111 риё зомее1та чзеЁи1 Беге 1афег 
</а1у> 
<а1у 4а="сопеепе"> 
<азр:СопеепЕР1асено1Аег Тр="МазпСопеепе" гипаф="зекуег" /> 
</алу> 
</Боау> 
</вЕт1> 


Подобный тип разметки НТМГ является признаком приложения АЗРМЕТ МУС. Он 
исключительно прост и имеет простую семантику: описывает содержимое, но ничего не 
говорит о том, как оно должно быть расположено на экране. Весь графический дизайн 
будет обеспечен с помонью стилей С$5'6. Давайте добавим файл С$$. 


16 Некоторые сильно устаревшие браузеры не поддерживают С$$. Однако поскольку эта тема 
касается дизайна (а книга посвящена платформе АЗРМЕТ МУС, в рамках которой можно с 
успехом визуализировать любую НТМГ-разметку), вопросы подобного рода рассматривать- 
ся не будут 
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Добавление правил С$$ 


В соответствии с соглашениями АЗРМЕТ МУС, статические файлы (вроде изобра- 
жений и файлов С$55) должны располагаться в папке /СопеепЕ. Добавьте в зту папку 
новый файл С$$ под названием зеу1ез.сз$ (щелкнув правой кнопкой мыши на пап- 
ке /Сопеепе, выбрав в контекстном меню пункт АО д=>Ме\ми Нет (Добавить=>Новый эле- 
мент), затем — Зе ЗНеет (Таблица стилей). 


Совет. Полное содержимое файла С$$ в книге приводится для справки. Набирать его вручную 
не понадобится, поскольку этот файл входит в состав материалов, доступных для загрузки на 
веб-сайте издательства. 


ВОРУ { ЕопЕ-Еаш41у: Сатрт1а, Сеохоафа, "Таиез Мем Вотап"; магаз: 0; } 
РТУ#ЬеаЧег ПТУ. 61Е1е, РТУ.1Еещ НЗ, РОТУ. 1еем Н4, ОТУ.радег А { 
Еопе: Бо1А4 1ем "Агта1 Магком", "ЕгапК11п СоеЬ1с МеЯа1ит", Аг1а1; 
} 
ОГУ Пеадег { Баскдгойпа-со1ог: #444; Богдег-БоЕЕош: 2рх золла #111; со1ог: ИнЕе; } 
рту#Веааег РТУ. %1е1е { Еопе-317е: 2еп; рааа1па: „бет; } 
РТУфсопеепЕ { Богдег-1еЕе: 2рх з011а дкау; таго1п-1еЕе: 9еп; рааа11а: 1еш; 
} 
РТУфрсафедок1е$ { Е1оае: 1еЕЕ; и1ЧЕЙ: Вет; раадлоа: „Зет; } 
ОТУ.1Еем { Богаег-Еор: Шрх аобЕеЯ дхау; рааа4та-вор: „.7еп; пахга1п-БоЕбой: „.7ещ; } 
РТУ .16еп: Е1кзЕ-ср1та { Богдег-сор:попе; рааалпа-кор: 0; } 
РТУ.1Еет НЗ { ЕопЕ-51=е: 1.3ет; магаз: 00 .25еп 0; } 
РТУ.16ет Н4 { ЕопЕ-$312е: 1.1ет; маголи:.4ет 000; } 
РТУ.радег { Еехё-а1190:г10№Е; рогаег-вор: 2рх 50114 з11уег; 
рада1т9: „5ет 0 0 0; мага1и-Еор: 1ем; } 
РТУ.радег А { ЕопЕ-51=хе: 1.1ем; со1ог: #666; техЕ-десогаклоп: попе; 
рааа119: 0 „.4ем 0 „4ет; } 
РТУ.радег А:Воуегк { Баскагоцпа-со1ог: $41 уех; } 
ОТУ.радег А.зе1есфея { раскакоцпа-со1ог: #353535; со1ог: Инаее; } 


И, наконец, установите ссылку на новую таблицу стилей, обновив заголовок <веа4> 
мастер-страницы /У1еиз/5вагеа/$1+е .Мазуег: 


<ВеаЯ гипаё="зегуег"> 
<Е1Е1е><азр:СопеепЕР1асено14ег ТР="Т1Е1еСореейе" кипае="зегуек" /> 
</Е1Е1е> 
< пк ге1="56у1езНеее" ргеё="-/Сопфкеп/з6у1ез.сз5" /> 

</веаа> 


На заметку! Символ тильды (-) указывает АЗР МЕТ, что путь к файлу таблицы стилей определяет- 
ся относительно корневой папки приложения, поэтому даже после развертывания брой$юге в 
виртуальном каталоге ссылка на файл С$$ останется корректной. Это работает только благо- 
даря тому, что дескриптор <Веаа> помечен как гипа{="зегуег", т.е. является серверным 
элементом управления. Подобный виртуальный путь нельзя применять в шаблонах представле- 
ний, потому что разметка выводится в том виде, как есть, и браузер сможет правильно интер- 
претировать символ тильды. Для преобразования виртуального пути в реальный служит метод 
0х1 .СопЕепе (например, <%= 0х1.СопеепЕ ("-/СопеерЕ/Р1скаге. 91Ё") $%>). 


Собственно, на этом все. Сайт теперь имеет, по крайней мере, подобие графического 
дизайна (рис. 4.18). 

После комбинирования мастер-страниц с правилами С$$ можно привлечь к рабо- 
те веб-дизайнера или загрузить какой-то готовый итаблон веб-страницы. При желании 
можно попробовать разработать дизайн страницы самостоятельно. 
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’ ЗРОВТ$ ЗТОВЕ 


ЗЕ ри : \ . р 
зотеНте изей а ВНио-БНпо Кто 


{7 Веге Мег | соа-рйавей, Фито -этаа ей Кое 


$1,200.00 


Рис. 4.18. Обновленная мастер-страница и стили С55$ в действии 


Создание частичного представления 


В качестве завершающего пттриха, давайте проведем неболыной рефакторинг прило- 
жения, чтобы упростить шаблон представления 1136 .азрх (как вы помните, представ- 
ления должны быть простыми). Вы узнаете, как создавать частичное представление 
(рагца! ем), выбирая фрагмент представления для визуализации товара и помещая его 
в отдельный файл. Частичное представление можно многократно использовать в раз- 
ных шаблонах представлений, к тому же оно позволит упростить [13 .азрх. 

В окне ЗоаНоп Ехрогег щелкните правой кнопкой мыши на папке /У1емз/5Вагеа и 
выберите в контекстном меню пункт АЗОР\Лем (Добавить=>Представление). В открыв- 
темся окне введите в качестве имени представления РкодисЕ битагу, отметьте флажки 
Сгеае а раг#а! Мем/ (.азсх) (Создать частичное представление (.азсх)), Сгеае а знопоу 
туреа чем (Создать строго типизированное представление) и в раскрывающемся спи- 
ске Мем/ дата с!а$$ (Класс данных представления) выберите класс модели Ропа1пМоае1 . 
ЕрЕ1Е1е3 .Рко@исЕ. Окно со всеми настройками показано на рис. 4.19. 


| да Лех 


ЗНезу пагле: 
Ресоосиоцититагу 


7 Стезёе а рама леч: {.а5с%) 


5 Ссвае в роов-ЬУреО ау 
ем даа аз: 
; Вогла Мое? Еле РробисЕ 


Алем: соифеге 


боге асе Ноег 0: 


Рис. 4.19. Настройки, используемые при создании 
частичного представления Ргодисе5биттаку 
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После щелчка на кнопке Ада (Добавить) среда \15ца1 Зна@1о создаст шаблон частич- 
ного представления в “/У1еиз/5Вагед/РходисЕ$иитагу.азсх. Он будет очень похож 
на обычный шаблон представления, за исключением того, что предназначен для ви- 
зуализации только фрагмента НТМГ-разметки, а не полной НТМТ-страницы. Поскольку 
РкодисЕ5иптаку строго типизирован, у него есть свойство по имени Моае1, для которо- 
го был установлен тип Ргодисе. Добавьте разметку для визуализации этого объекта: 


<$%@ Сопего1 Тапдпаде="с#" 

Тпбет15=" бузфем. Мер .Мус.У1ем0зегСопего1<рота1пМодет .Епе1те1ез.Ркодасе>" $> 
<а1у сТаз5="1ет"> 

<в3><$= МоЯе1.Маше %></н3> 

<$= Моае1 .Резсг1ре1оп %> 

<14><%= Мо@е1 .Рг1се.Тобег1па ("с") $></64> 
</азу> 


И, наконец, обновите /У1енз/Рходисез/Т13зе.азрх, чтобы он использовал новое 
частичное представление, передавая параметр ртодись, который будет присвоен свой- 
ству Моае1 частичного представления: 


<азр:СопеепЕ СопЕепЕР1асеНо1аегТр="Ма1пСопЕепе" гипаЕ="зегуех"> 
<% ЕогеасВ (уаг ргодиасе 1п Моде1} { %> 
<$ НЫй1 .БепдегРаг&1а1 ("РгодисЕбиттаку", ргодис®); %> 
<$ } %> 
<а1у с1азз="радег"> 
Раде: 
<%= Нем . Раде 4пК$ ( (10%) У1емрафа ["СигкепЕРасе"], 
(1012) Узеираба ["Тофа1Радез"], 
х => 0:1.АсСЕТог ("Та зе", пем { расе =х })) %> 


</91\> 
</азр:СопеейЕ> 


На заметку! Синтаксис, окружающий НЕт1 .БепаегРаге1а1 () ‚ несколько отличается от того, 
что окружает большинство вспомогательных методов НТМЕ. Вместо <*=...; %> используется 
<%...; 3>. Дело в том, что НЕм1 .ВепдетРакЕ1а1 () не возвращает строку НТМЕ-разметки, 
как большинство других вспомогательных методов НТМЕ. На самом деле он отправляет текст 
непосредственно в поток ответа, поэтому его вызов должен быть оформлен как завершенная 
строка кода С#, а не вычисляемое выражение С#. Теоретически он может использоваться для 
генерации огромных объемов данных, и буферизировать эти данные в памяти в виде строки, 
по меньшей мере, незффективно. 


Это вполне допустимое упрощение. Запустив проект снова, вы увидите новое час- 
тичное представление в действии (другими словами, внешне ничего не изменится), как 
показано на рис. 4.20. 


Резюме 


В этой главе была построена большая часть базовой инфраструктуры, необходи- 
мой приложению Эро юге. Несмотря на то что пока еще мало что можно продемон- 
стрировать визуально, “за кулисами” заложены основы модели предметной области с 
репозиторием товаров. основанном на базе данных ЗОГ. Зегуег. Также имеется один 
контроллер МУС под названием РгодисЕСорЕго11ех, который может генерировать 
постраничный список товаров, и контейнер С, координирующий зависимости меж- 
ду всеми этими частями. Вдобавок построена ясная специальная схема ОБТ, и теперь 
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можно приступать к написанию кода приложения. опираясь на солидный фундамент 
модульных тестов. 

В следующей главе будут добавлены все средства приложения, видимые извне: нави- 
гацию по категориям товаров, корзину для покупок, а также процесс оформления зака- 
за. Вот это уже можно будет продемонстрировать заинтересованным людям. 


| 
| 
| 
| 
| 


. МЛН ри 
| ы 
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Н 
8 РР 
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| . $16.00 
| 


Сопсеае4 Бигтег 
Зестейу 5 гасе уоиг орронети 


$4.99 


Нитап сНе$$ Боагд 


А №п вате юг тре иное ежмепдей фату} 


| $15.00 


Рис. 4.20. Серия частичных представлений РкодасЕ5иптагу.азсх 


ГЛАВА < 


Приложение 
рог оге: навигация 
и корзина для покупок 


В главе 4 была подготовлена большая часть базовой инфраструктуры, необходимой 
для построения приложения ЗрогЗоге. Реализовано построение простого списка 
товаров, который поддерживается базой данных ЗОГ, Зегуег. Однако для завоевания ли- 
дерства в глобальной электронной коммерции еще предстоит предпринять несколько 
действий. В этой главе вы продолжите процесс разработки АЗРМЕТ МУС, добавив нави- 
гацию по каталогу товаров, корзину для покупок и процесс регистрации заказа. В главе 
рассматриваются следующие вопросы. 


® Использование вспомогательного метода НЕт1.ВепдегАс+}оп {} для создания 
многократно используемых, тестируемых птаблонных элементов управления. 


* Выполнение модульного тестирования конфигурации маршрутизации (как входя- 
щей, так и исходящей). 


® Проверка данных перед отправкой формы. 


® Создание специального средства привязки модели (плоае! Ыпает), которое разделя- 
ет ответственность хранения корзины для покупок посетителя, позволяя сделать 
методы действий более простыми и тестируемыми. 


® Использование инфраструктуры инверсии управления (оС) для реализации под- 
ключаемого каркаса обработки заполненных заказов. 


Добавление элементов управления навигацией 


Приложение Зро{$юге будет более удобным, если вы позволите посетителям про- 
сматривать товары по категориям. Это можно реализовать в три этапа. 


1. Расширить действие 15 контроллера РгодисЕзСопего11ег возможностью 
фильтрации товаров по категориям. 
2. Усовершенствовать конфигурацию марптрутизации с целью доступа к каждой ка- 


з» 


тегории через “чистый” ОЕ|.. 


3. Создать список категорий для размещения в боковой панели с выделенной теку- 
щей категорией товаров и ссылками на другие категории. Для этого будет приме- 
няться вспомогательный метод НЕп1 .ВепдегАс1олп(). 
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Фильтрация списка товаров 


Первая задача заключается в расширении действия 113%, чтобы реализовать фильг- 
рацию товаров по категориям. 


Тестирование: фильтрация товаров по категориям 


Для поддержки фильтрации товаров по категориям добавим в метод действия г15 () дополни- 
тельный параметр 5Ех1.п9 и назовем его саб едохку. 


1. Когда значением саъедогу является пи11, метод 113 (} должен отображать все товары. 


2. Когда значением сабедогу является строка, №13 (} должен отображать только товары за- 
данной категории. 


Создайте тест для испытания зтого поведения, добавив новый метод [Тез®] к Ркодис®$ 
Сорфго11егТез®з: 


[ТезЕ] 
риаБ11с уо1а Базе Тас1адез А11 Ргодис&е$ ИВеп_Сафедогу 13 №11 () 
{ 
// Подготовить сценарий с двумя категориями 
ТРЕОодасезВероз1®оту героз1фогу = МоскРГгоаис*$Вероз1®огу ( 
пем Ргодисе { Маме = "Атфет1з", Сафедогу = "Сгеек" }, 
пем Ргодасе { Маше = "Мер®опе", Сафедогу = "Котап" } 
}; 
РЕгодасезСопехо11ех сопегоег = пем РкодисЕзСопего11ек (геро51®огу); 
сопЕго11етх.Радебуте = 10; 


// Запросить нефильтрованный список 
хаг гези1е = сопего11ег.Т1 зе (по11, 1); 


// Проверить, что результат включает оба элемента 
Аззеге. ТзМо №11 (хези1%, "Р1ац'Е гепаетх у1ем"); 
// Представление не визуализировано 
ухаг ргодасез = (11136 <Ргодис®>} гези1 .У1емрафа.Мо@е1; 
Аззег®.АкеЕаица1 (2, рходоасез.СоппЕ, "бое мгопа пошрег оЁ 1етз"); 
// Получено неверное количество элементов 
АззегЕ.АгеЕсца1 ("Атфет1з", ргодасез[0].Мате); 
АззегЕ.АгеЕдиа1 ("Мереипе", ргодисез[1].Мате); 
} 


Этот тест вызывает ошибку компиляции (№ охег1оа@ Бог шеброа '1156' вакез '2' ахдднепе$ 
(Нет перегрузки метода 1,1 5+, принимающей 2 аргумента)), потому что метод 113% () пока не 
принимает два параметра. Если бы не было вызова с двумя аргументами, этот тест прошел бы 
успешно, так как существующее поведение 1,15% () не поддерживает фильтрацию. 


Все становится несколько интереснее при тестирования второго поведения (когда отличное от 
пи11 значение параметра сабезогку должно вызывать фильтрацию): 


[ТезЕ] 

риуБ11с у01а Р15Е Е11%егз_Ву Сафедогу МЪеп_ Речаезфеа () 

{ 
// Подготовить сценарий с двумя категориями: Сафз и Родз 
ТРЕодисезВероз1оку героз1Еогу = МоскРЕкОодасЕзВероз1®огу ( 


пем РкодисЕ { Маше = "5помра11", Сафедогу = "Сафз" }, 
пем РходосЕе { Маше = "Вех", Сабедогу = "Род8" }, 
пеи Ргодис® { Мате = "“СаЕЁасе", Сафедоку = "Сафз" }, 


| 


пем РГОЧасе { Мате 
лем РгобисЕ { Маше 


"ИооЕег", Сабедогу = "Род5" }, 
"СБопрег", Сабедогу = "Родз" } 


| 
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РкодасеСопеко11ет сопего11ег = пем РеодисЕзСорЕго11ег (героз1фоту); 
сопЕго11етх.Радеб1те = 10; 


// Запросить только Роаз 
уах хези1еЕ = сопехо11ет. 11$ ("Родз", 1); 


// Проверка результатов 
АззекЕ. ТзМоЕ №11 (гезо1Е, "Р1ап’Е хепдет у1еи"); // Представление 
// не визуализировано 

уаг ркодасЕз = (1115Е<РходасЕ>) гезо1е.У1еирафа .Моде1; 
Аззеке.АгеЕаоа1 (3, ргоансе$.Соцпе, "СоЕ мгкопа пипег оЕЁ 1етз"); 

// Получено неверное количество элементов 
АззегЕ.АтеЕсица1 ("Вех", рходосез [0] .Мапе); 
Аззехе.АгеЕаоа1 ("МооЕех", рходисе$ [1] .Мате); 
АззетЕ.АтеЕачиа1 ("Сротрех", ргодосез[2].Мапе); 
Аззег®.АгеЕсца1 ("Родз", гези1е.У1емрафа ["СаггепЕСа®есогу"]}; 


} 


Как уже упоминалось, в таком виде скомпилировать эти тесты не удастся, поскольку 1,13 () 
пока не принимает два параметра. Таким образом, эти тесты требуют добавления в метод но- 
вого параметра сакедогу. Кроме того, тест также выдвигает еще одно требование: действие 
1156 () должно заполнять У1емрафа ["СихтепЕСафедогку" ] именем текущей категории. Это 
понадобится позже, при генерации ссылок на другие страницы той же категории. 


Начните реализацию с добавления нового параметра сатедогу в метод действия 
Т13е() класса РеобисЕзСопеко 11 ег: 


руЬ11с УземВезиа1 Т156Е(зЕх1па сабедогу, 11 раде) 
{ 


// ... Остальная часть метода не изменяется 


} 


Несмотря на отсутствие параметра сафедоху в конфигурации маршрутизации. это 
не помешает выполнению приложения. Если никакого значения не указано, АЗРМЕТ 
МУС просто передаст пи11 в качестве значения этого параметра. 


Тестирование: обновление тестов 


Прежде чем снова компилировать решение, понадобится обновить модульный тест 113 _ 
РгезепЕз СоггесЕе Раде ОЕ Ргодисее () ‚ чтобы он передавал некоторое значение в но- 
вом параметре: 


// Действие: запрос второй страницы (размер страницы = 3) 
уат гезы16 = сопего11ех.Т1 3 (по11, 2); 


ги11 — достаточно хорошее значение, потому что с тестом делать ничего не придется. 


Реализация фильтра по категориям 


Чтобы реализовать поведение фильтрации. обновите метод 113%() класса 
РхОобисЕзСопЕхо11ет следующим образом: 


рир11с УлемВезо1е 113% (зЕтлпа сафедогу, 1пЕ раде} 
{ 
уаг ргодисЕ5ТиСаеедоку = (са®едоку == пи11) 
? ргодисЕВероз16оту .Ргодасе$ 
: ргоаасеВероз1Еоку.РгодисЕ$ .МЪеге(х => х.Сафедоку == са®едогу); 
116 помРгодасЕ$ = ргодасёзТиСаведогу.Соип® (); 
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У1емРафа ["Тофа1Радез"] = (1п6)Маеь .Се111ла ( (Яоц61е) помРгодисез / Радеб1те); 
У1емрафа ["СиттепЕРаде"] = раде; 
Уземрава ["СиггепЕСа®едогу"] = сабедогу; // Для использования при 


// генерации ссылок на страницы 
гебиги У1ем (ргодисЕТпСаеедогу 
.ЭКТр ( (раде - 1) * Радебаее) 
.Таке (Радеб1те) 
„То () 
); 

} 

Этого достаточно для того, чтобы тесты компилировались и выполнялись. Более 
того — поведение можно наблюдать в веб-браузере, запросив ОВТ, вида ВЕ®р:// 
Тоса1ро5% : порт/ ?сафедогу=Иафегзрогез (рис. 5.1). Вспомните, что параметры строки 
запроса (в данном случае сабедоху) в АЗРМЕТ МУС используются в качестве парамет- 
ров методов действий (если на основе конфигурации маршрутизации не может быть 
определено другое значение). Прием зтих данных как параметров метода проще и более 
читабелен, чем извлечение их из коллекции Кедиез®е .Оцегу5 х1па вручную. 
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Рис. 5.1. Фильтрация товаров по категориям 


Чтобы заставить представление 113+.азрх визуализировать соответствующий за- 
головок страницы, как показано на рис. 5.1, обновите местоположение содержимого 
Веад: 


<азр:Сопеепе СопеепгЕР1асеНо1детТр="Т1Е1еСопееп®" гипаф="зекуег"> 
ЗрогЕз5еоге : 
<$= 56г1п9.15М№11ОгЕтреу ( (36.1143) У1емрака ["СиххепеСакедоку"]) 
? "АТТ РкоаисЕз" 
: Нем] .Епсоде (Утемрафа ["СиггепеСаведоку"]) 
$> 
</азр:СопеепЕ> 


В резульгате заголовок страницы будет отображать ЗрогЕз5$оге : НазваниеКатегории, 
если специфицировано У1емрата ["СиххепЕСафедогу"], и Зрогез5еоге : А11 РходасЕз 
(все товары) — в противном случае. 
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На заметку! Обязательно с помощью НЕт1 .Епсо@е () выполняйте НТМ!-кодирование всех 
введенных пользователем данных перед их обратной отправкой НТМЕ-странице, как это де- 
лается в предыдущем коде. Злоумышленник может ввести запрос вида /?саседоку=Вот+ 
такая+поддельная+категория и тем самым включить в вашу страницу произвольную 
строку. Если вы забудете использовать Нет] .Епсоде (} для кодирования ненадежного поль- 
зовательского ввода, то можете открыть ворота для угрозы атак межсайтовыми сценариями 
{сгоз$-зЦе зсирИпа — Х$5}'. Более подробные сведения о Х$$ и других проблемах безопасно- 
сти, а также о противостоянии даются в главе 13. 


Определение схемы ЦВЕ для категорий 


Мало кому понравятся неуклюжие ПЕ! вида /?сакедогу=Макехгзрогез. Как из- 
вестно, АЗРМЕТ МУС позволяет организовать схему ОНТ, любым подходящим образом. 
Простейший способ проектирования схемы ОНТ, состоит в написании последовательно- 
сти примеров желаемых ОНТ, как показано в табл. 5.1. 


Таблица 5.1. Проектирование схемы ЦВЕ на основе примеров 


Пример УВЕ Направление 

/ На первую страницу АЙ ргодис{$ (Все товары} 

/Раде2 На вторую страницу АЙ ргодис{$ {Все товары) 
/ЕооЕБа11 На первую страницу категории Роофа! (Футбол) 
/Еоора11/Раде43 На сорок третью страницу категории Роо1бай (Футбол) 
/АпуЕВ1та/Е1зе К действию Е1зе контроллера АпуЕЬ1паСопЕхо11ехк 


ВОВ 


те 3 ил 
Тестирование: отображение входящего маршрута 


Если вы кодируете в стиле ТОО, то сейчас самое время подготовить модульные тесты для вы- 
ражения конфигурации маршрутизации. Основная система маршрутизации, которая находится 
в сборке бузеет. Мер .КоцЕ1пад. 911, спроектирована для поддержки простого тестирования, 
так что проблем с верификацией обработки ею входящих строк ЦВЕ возникать не должно. 


Начните с добавления в проект Тез+з нового класса и назовите его ТороппаВоцЕ1п9Тезез. 
Тест для проверки отображения / (корневого ЦВЕ) может быть очень простым: 
[ТезеЕ1хЕоаге] 
руою11с с1азз ТироппаВои1таТезез 
{ 

[Тез*] 

РУЮ11с уо14 51азп боез То А11 Рходасез_Раде_1() 

{ 

ТезЕВомте ("^/", пем { сопехо11ехг = "РгоЧисез", асЕ1оп = "ТАЗЕ", 
сафедогу = (5Ег1109)па11, раде = 1 }); 


} 


На самом деле, тест не так уж прост. Приведенный выше код полагается на реализацию метода 
ТезЕВоцее (): 


' Теоретически атака подобного рода должны блокироваться средством проверки достоверно- 
сти запросов АЗРМЕТ, но эта защита может оказаться не достаточно надежной после ряда 
модификаций представления. Поэтому всегда применяйте Нем! .Епсосе ( ) перед отправкой 
любого пользовательского ввода. 
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ре1уаЕе уо14 ТезЕВотфе (3Ех1п4а их1, оюЗесе ехрескедУа1щез) 
{ 
// Подготовка: подготовить коллекцию маршрутов и макет контекста запроса 
ВоцфеСо11есЕ1оп гочЕез = пем КосеСо11ес Топ (); 
МусАрр11саЕ1оп .Кеч1зЕетгВосеез (хоцеез) ; 
уаг москнеЕрСопеехе = пем Моа.Моск<НЕЕрСопеех®Вазе>(); 
уаг поскВедаезЕ = пем Моа.Моск<НеЕрВесцез®Вазе> (); 
поскНеЕрСопЕехе .Зеьр (х => х.Кедиез®) .Вебигиз (поскВеачиез*.ОБ3ес®)}; 
поскКесдиезе.бебор (х => х.АррЕКе1а 1уеСиггепЕЕхесо&1о7тЕ11еРаЪ} .Вееикиз (ит1); 


// Действие: получить отображенный маршрут 
Воссера®а гопферафа = козфез .себвВоцеерата (поскНЕЕрСопеехе .ОБЗесе); 


// Утверждение: проверить значения маршрута на соответствие ожидаемым значениям 
Аззехге.Т5Мое №211 (госберака); 
уаг ехрессеЯр1се = пем ВосфеУа1ер1се1опагу (ехресфедУа1щез) ; 
ЕогеасЬ (уаг ехрескедУа1 1п ехресфеар1с+) 
{ 
1Е (ехрескеа\Уа1.Уа1ае == п:11) 
Аззете .Т15М№11 (гозеерафа .Уа1иез [ехресфеЯУа1 .Кеу]); 
е1зе 
Аззетф.АгеЕаца1 (ехресфед\а1 .Уа1ае.ТоЗегапа (), 
гопсерафа .Уа11ез [ехресфеЯУа1.Кеу] .ТозЕтг1та()); 


} 


Если вы недоумеваете, почему метод Тез Воц+е () (или подобный) не поставляется вместе 
с М\С, можно предположить, что это из-за того, что предложенная реализация при установке 
имитируемого контекста запроса полагается на Мод. Создатели М\УС не хотели принуждать раз- 
работчиков использовать какой-то один инструмент имитации. Если бы вместо Мод применялся 
пакет Ато Моск$, код был бы другим. 


Включите метод ТезЕВотее () в класс ТибочпаВочЕ1паТез+з, после чего скомпилирует код и 
запустите его в графической среде МИпй. Сейчас тест 51азВ соез То А11 Ркодисез Раде 1() 
пройдет успешно, потому что существующая конфигурация маршрутизации уже справляется с 
маршрутом -/ должным образом. Наличие определенного метода ТезЕБоцее () облегчает ло- 
бавление тестов и для других примеров ЦВЕ: 


[ТезЕ] 
руЮ11с \014 Раде2_боез То А11 Ргодасез Раде _2() 
{ 
ТезЕВосее ("-/Раде?", пем 
{ 
сопЕго11ег = "РходисЕз", асе1фоп = "154", 
саседогу = (51г119)0011, раде = 2 
}); 
} 
[Тез] 
роБ11с уо1а ЕооЪа11 Сбоез То Еоо{ра11 Раде 1() 
{ 
ТезЕВоцее ("-/Еоо®ра11", пем 
{ 
сопЕего11ек = "Рходас®з", асЕфоп = "зе", 
сафедогу = "Еоо{ра11", раде = 1 
}); 
} 
[Тез] 
рер11с у01а Еоора11 51азй Раде43 боез То _ЕГоо®ра11 Раде 43 () 
{ 
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ТезеВои*е ("-/ЕГоора11/Раде43", пеи 
{ 
сопЕго11ег = "РгодасЕз", асетоп = "Тв", 
сатедогу = "Еоофра11", раде = 43 
}); 
} 
[Тез] 
рию11с уо1а АпуЕ1п9 51азЪ Е1зе боез То Е1зе Оп АпуЕ|1паСопеко1 Тех () 
{ 
ТезЕВоцте ("-/АпуЕ1п9/Е1зе", пем {сопехо11ек = "АпуЬ1па", асетоп = "Е1зе"}); 
} 


Разумеется, прямо сейчас не все эти тесты пройдут, поскольку еще не сконфигурирована схема ЦВЕ. 


Тестирование: генерация исходящих ЦВ. 


Для полной проверки конфигурации маршрутизации понадобится создать модульные тесты также 
и для генерации исходяших ЦР. То, что входящая маршрутизация работает, еще не значит, что ис- 
ходящие ЦВЕ генерируются должным образом. Например, для доступа к одному и тому же ресур- 
су может быть предусмотрено несколько шаблонов ЦВЕ (например, сейчас /Раде? и /?Раде=2 
ведут к одному и тому же ресурсу), но какой следует сгенерировать ЦВЕ? Возможно, это не имеет 
особого значения, а, возможно, это является частью существующего контракта проектирования. 


Чтобы протестировать генерацию исходящих ЦВЕ, создайте в проекте Тезез новый класс под 
названием ОцеБоицпавоц1п9Тезез. Ниже приведен пример простого теста: 


[ТезеЕ1хеиге] 
рур11с с1азз ОпЕБонпаВоне1оаТезез 
{ 
[Тезе] 
РОБ с УО1&а А11 Ргодисе5_Раде 1 Тз АЕ 51азь() 
{ 
Аззете.АгеЕаиа1 ("/", СееОцЕБоцпЯ 0+1 (пем { 
сопЕго11ег = "РГОодис®з", асефоп = "аз", 
сафедогу = (5Ег1па)пи11, раде = 1 
})); 


} 


Как и ранее, чтобы это работало, потребуется реализовать метод СетоцЕБоцпа0т1 () (помес- 
тите его в ОцЕБоип9 Вон 1паТезез): 


зЕ:1па бебоиЕБонра0т1 (оБ]есе госфеУа1щез)} 

{ 
// Получить конфигурацию маршрута и имитацию контекста запроса 
ВоцЕеСо11есЕ1оп гоцЕез = пем Коц®еСо11ес1оп (); 
МусАрр11сае1оп .Кед1зеехВочеез (гоцфез); 
уаг поскНнеЕрСопеехЕ = пем Моа.Моск<НЕЕрСопеехЕВазе> (}; 
уаг поскВесиезе = пем Моа.Моск<НЕЕрВезиезВазе> (); 
уаг Еакевезропзе = пеи ЕКаКеВезропзе (); 
поскнеЕрСопфехе. 5ебор(х => х.Кеачиезе) .ВКебагиз (поскКечиезе.ОБдес®); 
поскнеерСопфехе.зееир (х => х.Кезропзе) .Вебоагиз (ЕакеВезропзе) ; 
поскКеацез*.Зееир (х => х.Арр11са1опРа\\№) .Вебоагиз("/"); 


// Генерация исходящего ОВЬ 
уаг сёх = пеи Веацез®Сопеех® (тоскНЕЕрСопеехЕ .ОЮЗесе, пем Восеерафа()); 
тебигп гофез .СееУ1гЕза1Ра®В (сх, пем Восбе\а1тег1сЕ1опагу (гоиееУа1щез) ) 
.У1туеоа1Раев; 
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рх1уафе с1азз Какевезропзе : НеЕрВезропзеВазе 
{ 
// Маршрутизация вызовов для сеансов, не использующих соокКле-наборы 
// На тест это не влияет, поэтому возвратить путь неизменным 
роЮ11с оуегт1ае зЕт1па Арр1уАррРа ЬМоа1Е1ет (зЕтлпа х} { хебагп х; } 
} 
Затем можно добавить тесты для других примеров ЦВЕ: 
[ТезЕ] 
роБ11с уола ЕооЬа11 Раде1 Тз АЕ 51азр Рооффа11 () 
{ 


Аззеге.АгеЕаца1 ("/Еоо®ра11", СееОцЕБоциЯ0т1 (печ 
{ 
сопЕго11ет = "Ртодисез", асфлоп = "Тазе", 
сафедогу = "ЕооЬа11", раде = 1 
})); 
} 
[Тез] 
рир11с у014 Еооа11 Раде101 Тз_АЕ 51азЪ Еоо®фа11 51азЪ_Раде101 () 
{ 
Аззеке.АгеЕаица1 ("/Еоо{ра11/Раде101", сеЕОсЕБочци@0т1 (пем 
{ 
сопЕго11етх = "Ргодисез", асёлоп = "Таз", 
сафедчогу = "ЕооЕфра11", раде = 101 
})); 
} 
[ТезЕ] 
риб11с уо1а Апу№1пчСопеко11ег Е1зе_АсЕ1оп_15_АЕ АпубЬ119 _$1азВ_Е1зе (} 
{ 


Аззехе.АгеЕсоа1 ("/АпуЕ1т9/Е1зе", СееОцЕБонпЯ0От1 (пем 
{ 


сопето11етх = "АПуЕЬ1та", асёлоп = "Е1 зе" 
})); 


Не рассчитывайте, что эти тесты сразу же пройдут, так как конфигурация схемы ЦВЕ пока еще 
не реализована. 


Реализуйте желаемую схему ОВТ, заменив существующий метод Вед1зеегВоиеез () 
(в С1оба1 .азах.сз) следующим: 


рию11с з6аф1с уола ВедазвехВонфез {ВоцфеСо11есЕ1оп гоп®ез) 
{ 
гопее$. Тапогевонее (" {хезоцтсе} .аха/ { *ра ВТпЕо}"); 
госеез .МарКочее (1011, 
"", // Совпадает только с пустым ОВЬ (т.е. ^/) 
лем { сопеко1Тех = "Рходисе$", асЕлоп = "Т1 8", 
сафедогу = (5Ег1п9)пи11, раде = 1 } 
}; 
гоцЕез .МарВос®е (по11, 
"Раде{раде}", // Маестез -/Раде2, -/Раде123, Бае поф ^/Радехуй 
пем { сопЕго1Лех = "Ргодасфз", асЕ1фоп = "113", сафедотху = (31109) 1011 }, 
рем { раде = @"\а+" } // Ограничения: номер странины должен быть числовым 
); 
госфе$ .МарКочцее (гл211, 
"{сафедогу}", // Совпадает с -/Коо{Ъа11 или ^/Апу Бата И1ЕЬМоЗ1азВ 
пем { сопёхо11ег = "Ргодасе$", асё1оп = "Т15Е", раде = 1 } 


); 
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гоцез .МарБои*е (п11, 

"{сафедогу} /Раде{раде}", // Совпадает с ^/ЕооЬа11/Раде567 

рем { сопего11ех = "Рходисез", асЕ1оп = "зе" }, // РеБас1з 

рем { раде = @"\а+" } // ограничения: номер страницы должен быть числовым 
}; 
топеез .МарВоцее (п11, "{сопёго11ех}/{ас1оп}")}; 


} 


Совет. Конфигурация маршрутизации может оказаться сложной! Система маршрутизации вы- 

бирает совпадающие входящие и исходящие маршруты, просматривая список сверху вниз и 
извлекая первый элемент маршрута, для которого обнаружено соответствие. Если злементы 
маршрута располагаются в списке в неверном порядке, возможен выбор неверного маршру- 
та. Например, если поместить {сакедогу} выше Раде{раде} в списке, то входящий ИВЕ 
/{Раде4 будет трактоваться как первая страница “категории” под названием Раде4. 
Золотое правило требует размещения наиболее специфичных маршрутов в начале, чтобы им 
всегда отдавалось предпочтение по отношению к менее специфичным. Тем не менее, иногда 
корректный порядок приоритетов для совпадений входящих маршрутов может конфликтовать 
с корректным порядком приоритетов для совпадений исходящих маршрутов. В таком случае 
для нахождения правильного порядка для обоих маршрутов понадобится экспериментировать, 
подбирая параметры сопзЕга1п+. В случае написания автоматизированных тестов для при- 
меров как входящих, так и исходящих отображений маршрутов решение этой задачи упроща- 
ется. Тесты позволят продолжить настройку конфигурации и проверять ее в графической сре- 
де МИпй, вместо того, чтобы каждый раз вручную просматривать весь набор возможных ЦВЕ. 
Более подробные сведения о маршрутизации вы найдете в главе 8. 

М 
И, наконец, имейте в виду, что когда вспомогательный метод Неп1. Раде лиК$ () ге- 

нерирует ссылки на другие страницы, категория пока не указывается, поэтому посе- 

титель не узнает, товары какой категории он просматривает. Обновите вызов метода 

Ни] .Раде1тК$ () в Т13е.азрх: 
<%= Нет1 .Раде кз ( (10%) У1емрата ["СиггепЕРаде"], 

(1716) У1темрафа ["Тофа1Радез"], 
х => 0:1.Асетоп ("Т15%", пем { раде = х, 
сафедоку = УземРака [ "СиххепеСаведогу"] })) %> 
После этого вы обнаружите, что все модульные тесты теперь проходят успешно. 


Если вы перейдете на ОЕ. вроде /Свезз. то все ссылки на страницы обновятся, отра- 
жая новую схему ОВ (рис. 5.2). 
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Рис. 5.2. Улучшенная конфигурация маршрутизации порождает чистые ЦВЕ 
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Построение меню навигации по категориям 


Когда посетитель запрашивает допустимый ОЕ. категории (например. /СЪезз или 
/Зоссех/Раде2), существующая конфигурация ОВТ. корректно разбирает его, а кон- 
троллер РЕОобасЕзСопехго11ег выполняет свою работу по представлению соответствую- 
щего списка товаров. Но где посетитель сможет обнаружить хоть один из таких ОВ? 
В приложении нет ссылок, которые ведут к ним. Значит, пришло время поместить что- 
то полезное в боковую панель приложения, в частности — список категорий товаров. 

Так как зтот список ссылок на категории будет совместно использоваться многи- 
ми контроллерами, и поскольку это отдельная ответственность по своей сути, для его 
представления должен быть предусмотрен какой-нибудь повторно используемый эле- 
мент управления, или виджет (графический элемент пользовательского интерфейса). 
Как же его построить? 


Должен ли это быть простой вспомогательный метод НТМЕ наподобие 
НЕп1.РадерлиКз ()? Возможно, но тогда теряются преимущества от визуали- 
зации меню через шаблон представления (вспомогательные методы НТМГ, про- 
сто возвращают НТМГ-разметку из кода С#). Чтобы поддержать возможность 
генерации более изощренной разметки в будущем, давайте найдем некоторое 
решение, использующее шаблон представления. Также визуализация посред- 
ством шаблона представления означает, что вы сможете написать более ясные 
тесты, потому что не придется сканировать специфические НТМГ-фрагменты. 


Должно ли это быть частичное представление вроде РкодисЕ биттаку.азсх из 
главы 4? И снова нет — ведь это просто кусочки шаблонов представлений, ко- 
торые не могут содержать никакой логики приложения; в противном случае вы 
скатитесь к временам “супа из дескрипторов”? классического АЗР, и такая логи- 
ка не поддается тестированию. Но этот виджет должен включать в себя некото- 
рую логику приложения, так как он должен получить список категорий из репо- 
зитория товаров и определить, какую из них выделить в качестве “текущей”. 


В дополнение к базовому пакету АЗРМЕТ МУС предлагается дополнительная сборка 
под названием АЗРМЕТ МУС Егаёигез. Эта сборка. (М1сгозоЕе.Меь.Мус . 911) содержит 
набор дополнительных средств для МУС, которые предполагается включить в следую- 
щую версию основного пакета. 

Одно из расширений М1 скозоЕЕ.Меь .Мус.а11 предоставляет идеальный способ 
реализации многократно используемого навигационного виджета. Это вспомогательный 
метод НТМЕ под названием Нби1.ВепдекАсЕ Топ (), который просто позволяет вклю- 
чить вывод от произвольного метода действия в вывод любого другого представления. 


2-Суп из дескрипторов” (ва5 зоир) — термин, присвоенный худшему стилю программирова- 
ния в классическом А$ЗР с чрезмерно перегруженными сложными файлами .азр, в которых 
логика приложения (установка соединения с базой данных, чтение и запись файловой сис- 
темы, реализация важной бизнес-логики и т.п.) переплетена непосредственно с тысячами 
фрагментов НТМГ-рахметки. Такого рода код не обеспечивает разделения ответственно- 
сти и крайне затрудняет его сопровождение. Злоупотребление шаблонами представлений 
АЗРМЕТ МУС может дать тои же эффект 


з Некоторые разработчики жалуются, что Нет .ВепаегАсе1от() нарушает нормальное 
разделение ответственности в приложении МУС. С другой стороны, те, кому приходи- 
лось работать с АЗРМЕТ МУС в рамках достаточно болыших проектов, утверждают, что 
на самом деле это элегантный инструмент, который хорошо поддерживает модульное 
тестирование, и во многих случаях НЕп1.ВепаегАсе1оц () или подобные ему альгерна- 
тивы являются единственно возможным выбором. Этот и также совершенно другой подход 
подробно рассматриваются в главе 10. 


Глава 5. Приложение Зрой{юге: навигация и корзина для покупок 141 


В данном случае, создав новый класс контроллера (назовем его МауСопЕго11ет) с 
методом действия, который визуализирует навигационное меню (назовем его Мепл ()}, 
можно внедрить вывод метода действия непосредственно в шаблон мастер-страницы. 
МауСорего1Тег будет реальным классом контроллера, поэтому он может включать логику 
приложения, оставаясь легко тестируемым, а его действие Мепо () будет визуализировать 
завершенную НТМГ--разметку с использованием нормального шаблона представления. 

Прежде чем продолжить, не забудьте загрузить сборку АЗРМЕТ МУС Еесабалге$ из сай- 
та ммм. соаер1Тех .сом/азрпе®/ (загляните на вкладку В@еазе$ (Выпуски)) и добавить 
ссылку на нее в проект Мебот. Затем импортируйте пространство имен М1сгозоЕф. 
\еь .Мус во все представления, добавив следующую строку в узел зузсеп.меб/радез/ 
памезрасез файла меь . сопЁ19: 


<папезрасез> 
«аа памезрасе="МаскозоЕ& .Мер.Мус" /> 
</патмезрасез> 


После этого метод НЕт1 .ВепдегАс&1оп () станет доступным всем пгаблонам пред- 
ставлений. 


Создание контроллера навигации 


Начните с создания нового класса контроллера МахСопЕго11етх внутри папки 
/Сорехо11етгз проекта \ерот (щелкните правой кнонкой мыши на папке /Сопего11етз 
и выберите в контекстном меню пункт АЯЧР Сотгойег (Добавить> Контроллер]}}. 
Добавьте в МауСорехго11ет метод Мепл () , который пока что возвращает некоторую тес- 


товую строку: 


патезрасе Мер0Т.Сопето11етз 
{ 


руЮ11с с1аз$ МауСопЕго11ек : Соп®го11ек 


{ 
рор11с зЕт1па Мепа () 


{ 


тебагп "Не11р Егом МауСопего11ег"; 


} 
} 


Теперь можно включить вывод этого метода действия в боковую панель каждой стра- 
ницы, обновив элемент <Ъоду> мастер-страницы /У1ем$ /ЗВагеЯ/51е .Мазтег: 


<роау> 
<Ч1у 19="реадех"> 
<С1у с1азз="{11е">5РОВТ$ ЗТОВЕ</Я1\> 
</91у> 
<Я1у 19="сафедоглез"> 
<% НЕм1.ВепехАсЕлоп ("Мепа", "Мам"); %> 
</91у> 
<Ч1у 19="сопфер®"> 
<азр:СореерЕР1асеНо14ет Тр="Ма1пСопфеп®" гопа®="зетуегк" /> 
</алу> 
</роду> 


Внимание! Обратите внимание, что синтаксис, окружающий Нет] .ВепдехАс®тол () ‚ подобен син- 
таксису, окружающему НЕт1 .Вер@егРаг®1а1 (). Вместо <%= Нет1.ВепаекАс®1от(...) %> 
применяется <% НЕт1 .ВепаегАс {оп (...); %>. Метод не возвращает строку; из соображений 
производительности он просто направляет свой вывод непосредственно в поток Везропзе. 
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Если теперь запустить проект, можно будет увидеть вывод действия Мепо () класса 


МауСопЕто11ех, включенный в каждую сгенерированную страницу (рис. 5.3). 
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Рис. 5.3. Сообщение МауСопего11ет, включенное в страницу 


Теперь осталось только расширить МауСопЕхго11ег, чтобы он в действительности 


визуализировал набор ссылок на категории. 


И 


Тестироввние: генерация списка ссылок нв категории 


МауСопехо1Тетх — это настоящий контроллер, поэтому он подходит для модульного тестиро- 
вания. Необходимо реализовать следующее поведение. 


МауСопЕго11ет принимает ТРхочисе ВерозА®окгу в качестве параметра конструктора 
(зто означает, что контейнер |оС заполнит его автоматически). 


Он использует ТРходисезВероз1огу для получения набора отличающихся категорий в 
алфавитном порядке. Он должен визуализировать свое детальное представление, передавая 
Моае1 экземпляр ТЕпотегаю1е<МауАпК>, где каждый объект Мать 1пК (пока не опреде- 
ленный) описывает текст и информацию маршрутизации для каждой ссылки. 


Кроме того, он должен добавлять в начало списка ссылку на домашнюю страницу сайта (Нопе). 


Ниже приведены два модульных теста, описывающих представленное выше поведение. Они долж- 
ны быть помещены в новый класс тестовой оснастки МауСоп%го11етТез®з проекта Тез\з: 
[ТезеЕ1хе оке] 

руЮ11с с1азз МауСор&тго11етТез®з 


{ 


[Тезе] 
риЮ11с Уо1а Такез ТРГОоЧосЕзВероз1оку Аз СопзЕгасфог Рагам() 
{ 
// Тест "проходит", если он компилируется, 
// поэтому здесь не нужны утверждения 
пем МауСоп©го11ехт ( (ТРгоаис® зВероз1®огу) по11); 
} 
[ТезЕ] 
РУБ11с уо1а Ргодисез Ноше Р1а5 МауЪлок ОБ]есЕ Еог ЕасВ Р213Е1пс® Сафедогу() 
{ 


// Подготовка: репозиторий товаров с несколькими категориями 
ТОцегуа61е<Рго@ис®> ргодас®$ = пем |[] { 

реи Рго@ас® { Маше = "А", Сафедогу = "Ап1ша!" }, 

пеи Ргоаис® { Мапе "В", Сафедогу = "УедефаЮ1е" }, 

пем Ргобисе { Маше = "С", Сафедогу = "М1пега1" }, 


| 
| 
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пем РгоаосЕ { Мане = "Р", Сафедогу = "УедефаЮю1е" }, 

пем Ргоаос® { Маше = "Е", Сабедогу = "Ап1та1" } 
}.АзОцегуаЬ1е (); 
уаг поскРгодис®зВероз$ = пем Моа.Моск<ТРкодис® Вероз1еогу> (); 
носкРЕоаЧосезВероз .Зефар(х => х.Ргоаыс®з) .Вебогпз (ркодосез) ; 
уаг сопего11ек = пем МауСопего11ет (посКРгодис®$Вероз.ОЮ]ес®); 


// Действие: вызвать действие Мепа () 
У\У1еиВезо1% гезо1Е = сорЕго11ег.Мепа(); 


// Утверждение: проверить визуализацию по одной Мау 1пк на категорию 
// (в алфавитном порядке) 
уахг 11пК$ = ((ТЕпопека61е<Мау1.1пК>) кези1Е .У1емрака.Мо4е1) .Тог1 зе (); 
Аззеге. ТзЕпр®у (гезо1&.У1емМаше); // Должно визуализировать 
// представление по умолчанию 
Аззеге.АгеЕааа1 (4, 11пК$5.Сопп®); 
Аззекге.АгеЕааа1 ("Нопе", 11пкз[0].Тех®); 
Аззегс.АтеЕаоа1 ("Ап1та1", 110К$[1].Техе); 
Аззетг&.АгеЕдиа1 ("М1пега1", 11пк3[2].Техё); 
Аззег®.АгеЕааа1 ("Уедефаю1е", 11пк5[3].Тех®); 
Гогеась (уак 11р0К 1п кз) 
{ 
Аззеге.АтеЕааа1 ("РгоаасЕз", 11пк.ВосфеуУа1лез ["соп©го11ег"]); 
Аззеге.АгеЕаоа1 ("1.135", ик. Вочкеуа1щез ["ас®1оп"]); 
Аззек®.АгеЕана1 (1, ик.Воч<еуа1щез ["раде"]); 


ЛЕ (11пК5 .ТиаехоОЕ (110К) == 0) // Является ли зто ссылкой Нопе? 
Аззеке. 15М№211 (11пКк.ВоссеуУа11ез ["са<едогку"]); 
е1зе 


Аззеке.АгеЕаца1 (11пк.Тех®, 11пк.ВоисеУа1щез ["сахедогу"]); 


} 


Тест вызывает появление множества ошибок компиляции, обусловленных разными причинами. 
Например, действие Мепо () в данный момент не возвращает У1е\Вези1* (а возвращает стро- 
ку), и еще не существует класс по имени МауТ1 пк. Здесь снова тесты выдвигают некоторые 
новые требования к коду приложения. 


Выбор и визуализация списка ссылок на категории 


Модифицируйте контроллер МауСопЕго11ех, чтобы он генерировал соответствую- 
щий список категорий. Для извлечения списка отличающихся категорий ему понадо- 
бится предоставить доступ к интерфейсу ТРхОодис*Вероз1%огу. Если передать его в 
параметре конструктора, то контейнер 10С сам позаботится о передаче подходящего 
экземпляра во время выполнения. 


пашезрасе МеьОТ .Сопфго11ет5 
рар11с с1фазз МауСоп®ко11ек : Сопего11ег 
ре1уаее ТРгоаис©зВероз1$огу ркодосезВероз1$огу; 
руЮ11с МауСопего11ет (ТРкоаис® $Вероз1$оку ргодас&Вероз1еогу) 
{515$ .ргоаис®$Вероз1$огу = ргодосёзВеро$1%оку; 
а У\У1еиВези1* Мепц () 
{ 
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// Поместить в начало ссылку Нопе 

Т1э<<МауГ1пКк> рауГликз = пем 11з<МахЛек>(); 

пауЪ1пк$ .АЧа(пем Сабедоку! ик (по11)); 

// Добавить ссылку для каждой отличающейся категории 

уУаг саФедоглез = 

ргодисеВероз1еоку.Ркодасьв .Зе1ес® (х => х.Сафесохгу); 

ЕогеасВ (51119 сабедогу 1п сабедог1ез.0181пс\ () .ОтаекВу(х => х)) 
пауТ1пкз.АЯЯ(пеи Сабедоку! ик (сабедоку)); 

тесакп Улеи (пауГ.1пкз); 


рир11с с1азз Мау Шик // Представляет ссылку на произвольный элемент маршрута 
{ 
роЮ11с зЕг1п9 Техе { де®; зеф; } 
рыуБ11с ВопееУа1аер1сЕ1опагу ВоцееУа1щез { её; зец; } 
} 
РаБ11с с1азз СакедогуТапк : Мау ок // Специфическая ссылка на категорию товаров 
{ 
руЮ11с СафедокутТл1 пк (з&х1па сафедоку) 
{ 
ТехЕе = саеедогку ?? "Нопе"; 
ВостеуУа1щез = пеи ВосфеУуа1щер1с®1опаку (пем { 
соп&тго11ег = "Ргодис® 5", ас®1ов = "ГА вс", 
саседогу = сабедогу, раде = 1 


}); 


} 


Внесенные изменения позволят модульным тестам компилироваться и успешно про- 
ходить. Здесь генерируется коллекция объектов Мау 1пк, в которой каждый экземпляр 
МауТ1пк представляет ссылку, подлежащую визуализации (специфицируя и текст, и 
значение маршрута, определяющее целевое назначение ссылки). 

Однако если вы теперь запустить проект, появится сообщение об ошибке Тпе меми 
"Мепи’ ог #$ тазег сои пот Бе Гоипа. ТПе юНо\ипа юсаНопз меге зеагсйен: —/УМемз/ 
Мам/Мепи.азрх, -/\Лем/Мам/Мепи.азсх (Представление Мепи или его владелец не най- 
дены. Поиск выполнялся в следующих местоположениях: ^-/У1емз/Мау/Мепо. азрх, 
-/У1емз/Мау/Мепи.азсх). Это не должно быть сюрпризом: вы просили действие Мепо () 
визуализировать свое представление по умолчанию (одно из указанных местоположе- 
ний), но ни в одном из них пока ничего нет 


Визуализация частичного представления из действия Мепиа 


Поскольку этот навигационный виджет должен быть лишь фрагментом страницы, 
а не целой страницей, имеет смысл, чтобы его шаблон представления был частичным, 
а не обычным. Ранее вы визуализировали частичные представления только вызовом 
Н\го1 .ВепдегРаг®1а1 () ‚ но как вскоре будет показано, визуализацию частичного пред- 
ставления может выполнять любой метод. Это особенно удобно, когда используется вы- 
зов Нт1 .ВепаегАс&1Топ () либо технология Адах (см. главу 12). 

Чтобы создать представление для метода действия Мепо () класса МауСопЕго11ек, 
щелкните правой кнопкой мыши внутри тела метода и выберите в контекстном меню 
пункт АДА \Мем (Добавить представление). В открывшемся окне отметьте флажки 
Сгеае а рагНа! ем (Создать частичное представление} и Сгеа а зопау фуреЯ мем 
(Создать строго типизированное представление) и в поле с раскрывающимся списком 
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\Мем/ Чата с!аз$ (Класс данных представления} введите Тепипегар1е<Иерот. 
СопЕго11ет$ .Мау1пк>. Теперь можно добавить разметку, генерирующую дескриптор 
ссылки для каждого объекта МауТ1пК: 


<5@ СопЕго1 Гапдааде="С#" 
Трвег1& = 
"бузеет.Меь .Мус .УлемОзегСопеко1<ТЕпомегар1е<Иер0Т .Сопёто11етз .МахТ4ик>>" %> 
<% ЕогкеасВ (хак Лик 1п Моае1) { %> 
<а ВтеЕ="<%= 0т1.Возее0к1 (110К.Вочбеуа1щез) %$>"> 
<%= 14рк.ТехЕ %> 


Чтобы улучшить внешний вид ссылок, добавьте несколько правил С5$ в файл 
/Сопхепе/зку1ез.с33: 


РТУ#сабевот1ез А 

{ 
Еопе: Бо1а 1.1ем "Ак1а1 Магком", "Егапк11п СоЕр1с Меа1том",Аг1а1; 
Ч1=р1ау: Ю1оск; 
техЕ-десога1оп: попе; раЯ91па: „беш; со1ог: В1асК; 
Богаег-Ботфот: 1рх 30114 в11уек; 

} 

РТУ#сакедог1ез А.зе1есееа { БаскакоипЯ-со1от: #666; со1ох: ИБ1е; } 

РТ\У# саседог1ез А:Бо\егк { БаскагоцпЯ-со1ог: #ССС; } 

РТУ+сакедог1ез А.зефесееа:Воуег { БаскКахоспа-со1ог: #666; } 


Теперь можно посмотреть на резульгат (рис. 5.4). 
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Рис. 5.4. Ссылки на категории, визуализированные в боковой панели 


Выделение текущей категории 


Список ссылок на категории пока что не поддерживает одно очевидную особенность: 
элементы управления навигацией обычно должны каким-то образом выделять текущее 
местоположение посетителя. Это указывает посетителю. где именно он находится в 
виртуальном пространстве сайта, делая его работу более комфортной. 
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Тестирование: выбор правильного элемента мау пк для выделения 


Логику выбора ссылки для выделения имеет смысл поместить в МауСор+хо11ех, анев пред- 
ставление (Мепи.азсх). 


Причина в том, что изначально предполагается, что шаблоны должны быть “неинтеллектуальнь- 
ми” — они могут содержать простую презентационную логику (выполняющую, например, итера- 
цию по коллекции), но не должны включать прикладной логики (например, принятие решений о 
том, что показывать наблюдателю). Сохранение прикладной логики внутри классов контроллеров 
обеспечивает ее тестируемость. Кроме того, страницы АЗРХ/АЗСХ никогда не превратятся в “суп 
из дескрипторов” с полным несоответствием НТМЕ-разметки и прикладной логики. 


Каким же образом поступить в данном случае? Естественное решение состоит в добавлении в 
класс МауТ1 пк флага Боо1 (Под названием, например, Тз5е1ескеа). Он может устанавливать- 
ся в коде контроллера и служить в представлении в качестве триггера для визуализации соот- 
ветствующей разметки. Но как контроллер определит текущую категорию? Он может потребовать 
передачи категории в качестве параметра методу действия Мепл (). 
Ниже приведен тест, который выражает это проектное решение. Добавьте его в МауСопего11ехТез: 
[ТезЕ] 
руБ11с уо1а н1901198%з_Соккеп® Сафедоху () 
{ 
// Подготовка: репозиторий товаров с парой категорий 
ТОпегуаЬ1е<Рго@аис®> рго@ас®в = пеи[] { 
рем Рго@асЕ { Маме = "А", Сафедогу = "Ап1ша1" }, 
реи РгоЧисЕ { Маме = "В", Сабедогу = "Уедефа61е" }, 
}.АзОцегуа1е (); 
Уаг поскРгодас©$Вероз = пеи Моа.Моск<ТРгодис&Вероз1еогу> (); 
поскРЕОЧисЕ3Вероз .Зесор(х => х.Ргодиси$) .Вероги$ (ргодисЕз); 
уак сопего11ег = пем МауСопего11ех (москРгоаосЕ$Вероз.063ес\); 


// Действие 
уаг гезо1Е = сопего11ег.Мепа ("УедегаЪ1е"); 


// Утверждение 

уаг №1911 ареЯт1пкз = ((ТЕпошекаь1е<Мау1АикК>) гезо1е.\У1еирата.Моае1.) 
.ИБеге (х => х.1з5е1есфеа) .Тор1з®(); 

Аззеге.АгкеЕдиа1 (1, Бао 11тарееатАтк$ .СоппЕ); 

Аззеге.АгеЕаца1 ("УедефкаЬ1е", 11911196 %еа11ткз[0].Техь); 


} 


Естественно, сразу же скомпилировать зтот тест не получится, ПОСКОЛЬКУ Мау. 1пК еще не имеет 
свойства Тзбе1есфеа, а метод действия Маз п () пока не принимает никаких параметров. 
АННЕ Е БЬЕТ 


Давайте реализуем выделение текущей категории. Начните с добавления к МауТ1пк 
нового свойства типа Боо1 под названием Тз$е1ес\еа: 


ро611с с1азз МауГлок 

{ 
ру11с зЕг1па Тех { деф; зе®; } 
рор11с ВооееУа1щер1сЕ1опраку Вочее\а1щез { деф; зег; } 
риБ11с Боо1 ТзЗе1есфе@ { деф; зе; } 

} 


Затем обновите действие Мепи () класса МауСопего11ек, чтобы оно принимало пара- 
метр 6191119 еСахедоку, используемый для выделения соответствующей ссылки: 


РаБ11с УлемКеза1е Мепи (зЕх2по №1911 96Сабедогу) 
{ 


// Поместить в начало ссылку Нопе 
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Т1в5<Мау1Глик> пауГлпкз = пеи 113%<Мау Г лиК> (); 
пауГапКз .Ааа (пем Саведогу! лик (г11) { 
ТзЗе1есвеа = (619411396 Сабедогку == 1п'211) 
}); 
// Добавить ссылку для каждой категории 
Уаг сафедок1ез = ргодисЕ;Кероз1еогу. РкоЧасе$.бе1есе(х => х.Сафесвогу); 
ЕогеасВ (з%г1па сафедогу 1п сафедог1ез.р1$%1пс®() .Окхаекву(х => х)) 
вау 1оКз.АЯа (пе Сафедогу11тК (са®едогу) { 
ТзЗе1есфеЯ = (саёедогу == №1951196%Сафедогу) 
}); 


гебакп У1еми (пауТГлоКз$); 


Тестирование: обновление тестов 


На данный момент скомпилировать решение нельзя, потому что тест Ргодасез_Номе_Р1аз_ 
МауЪ1пК ОЮЗесЕ Гог Еась 01$%1псе Сабедогу() (в МауСопего11егТез% 5) вызыва- 


ет Ма1т () , не передавая никакого параметра. Модифицируйте его, добавив передачу парамет- 
ра, как показано ниже: 


// Действие: Вызвать действие Мепа() 
У1емВези1® гезы1Е = соп®го11етг.Мепа (по11); 


Теперь все тесты должны проходить, демонстрируя, что Ма”СопЕтго11етх может выделять пра- 
вильную категорию. 


В завершение обновите вызов Ма1п () в /У1емз /5пагеа/51%е .Мазфег, чтобы при 
генерации навигационного виджета указывалась категория для выделения: 


<а1у 19="сафедок1ез"> 
<% Нт1.ВепдегАс®1от ("Мепа", "Мау", 


пем { 61961196 &Саеедоку = Уземрава["Сиггеп®Саеедогу"] }); %> 
</а1х> 


Затем обновите шаблон /Уземз /Мау /Мепи .азсх для генерации специального класса 
С$5, который будет отвечать за внептний вид выделенной ссылки: 


<5 ЕокеасВ (уак ШиК 1п Мо@е1) { %> 
<а Вкеё="<%= 0у]1.Вопфе0к1 (11пКк.ВоцееУа1щез) %>" 


С1азз="<%= 110К.Тзбе1есееЯ ? "зе1есфеЯ" : "" $>" 
> 
<%= мок.Техе $%> 
</а> 
<$ } %> 


В конечном итоге получен работающий навигационный виджет, умеющий выделять 
текущую страницу (рис. 5.5). 


Построение корзины для покупок 


Разрабатываемое приложение уже выглядит намного лучше, но с его помощью пока 
что нельзя продавать спортивные товары — отсутствуют кнопки для покупки и корзина 
для покупок. Настало время заняться и этим. 
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Рис. 5.5. Навигационный виджет выделяет текущее местоположение посетителя 


В данном разделе вы сделаете следующее. 


Раситирите модель предметной области для представления понятия корзины для 
покупок (Саг®) с поведением, определенным в форме модульных тестов, и разра- 
ботаете второй класс контроллера — СахСопето11ег. 


Создадите специальное средство привязки модели, которое обеспечит для мето- 
дов действий элегантный (и тестируемый)} способ получения экземпляра Саг®, 
относящегося к текущему сеансу браузера посетителя сайта. 


Узнаете, чем полезно использование множества дескрипторов <Еоги> в АЗРМЕТ 
МУС (в АЗРМЕТ \ебЕогпа$ это было почти невозможно). 


Увидите, как использовать Нет1.ВепдекАс®1оп() для быстрого и простого соз- 
дания элемента управления, подсчитывающего итоговый результат по корзине 
(в сравнении с созданием МауСопеко11ех, что было непростой задачей). 


В общем и целом, вы реализуете процесс работы с корзиной для покупок, описанный 
на рис. 5.6. 


Столовые приборы Вашакорзина Ввод информации 


Нож 


о доставке 


Вилка | Добавить в корзину итд. 


Всего: $9.95 


Ложка | Добавить в корзину 


Продолжить покупку 


Рис. 5.6. Набросок рабочего потока корзины для покупок 


На экранах списка товаров рядом с каждым наименованием должна быть кнопка 
добавления в корзину (АЧЯ 10 сай). Щелчок на ней должен приводить к добавлению 
единицы товара в корзину для покупок и переносить посетителя на экран содержимого 
корзины (\%оиг сай). Помимо содержимого корзины, на зтом экране отображается ито- 
говая сумма, а также кнопки, позволяющие продолжить покупку (Соп#пие $Порри1д) и 
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оформить заказ (Спеск оц! пом. Щелчок на кнопке Сопптие зпорртод приведет к воз- 
врату посетителя на страницу, где он был перед зтим (в ту же категорию и на ту же 
страницу), а щелчок на кнопке СНеск оц пом/ переносит на экран, на котором можно 
завершить оформление заказа. 


Определение сущности Саке 


Поскольку корзина для покупок — часть предметной области приложения, Саг& име- 
ет смысл определить как новый класс модели. Поместите класс по имени Саг& в папку 
Епс1С1ез проекта РасаМоде1: 


папезрасе Рома1пМоае1 .Ере1Е1ез 
{ 
руБ11с сфа$$ Сакё 
{ 
рг1уаее 1.13Е<СакЕТГ1те> 11рез = пеи 115$6<Сак®Т.1пе> (); 
рир11с 111$6<СакЕ11пе> 11рез { деё { гебаги 11тез; } } 
рур11с у01а АааТ® ем (Ргодас® ргодас®, 116 апапЕ1у) { } 
ро11с аесИипа1 СотриееТо$а1Уа1ще() { Егом пем МоЕТир1епереедЕхсер® Топ (); } 
р9Б11с уо14А С1еак() { Югом пем МоЕТар1етерфеЯЕхсер ол (); } 
} 
рор11с с1а$$ СакЕГ ле 
{ 
рур11с Ркодас® Ргодас® { де; зеё; } 
роБ11с 116 ОпапЕ1еу { деё; зеф; } 
} 


} 


Лучшим местом для помещения модели предметной области является логика пред- 
метной области, или бизнес-логика. Это поможет разделить ответственность предмет- 
ной области и веб-приложения (запросы, ответы, ссылки, страницы и тп.}, которая 
обычно располагается в контроллерах. Поэтому следующим шагом будет проектирова- 
ние и реализация следующих связанных с Саг® бизнес-правил. 


® Корзина изначально пуста. 


® Корзина не может иметь более одной строки для каждого товара. (Таким образом, 
при добавлении товара, для которого в корзине уже имеется строка, просто уве- 
личивается его количество.) 


® Итоговая сумма по корзине равна сумме цен каждого наименования товара, ум- 
ноженных на количество. (Для простоты мы опускаем все, что касается оплаты 
за доставку.) 


Тестирование: поведение корзины для покупок 


Существующие простейшие реализации Саг® и СахЕТ1пез служат хорошей отправной точкой 
для определения их поведения в терминах тестов. Создайте новый класс Саг%Тез® в проекте 
Тез®5: 

[ТезеЕ1хсоте] 

29511с сфазз СагЕТезе$ 


[ТезЕ] 
рор11с уо1а СагЕ Зеаг®з Епрёу () 
{ 


Саке саге = пеи Сак®(); 
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Аззег&.АтеЕза1 (0, саге.Т1пез.Сошо®); 
Аззек©.АгеЕоа1 (0, саге.Сотры®еТофа1Уа1ще ()); 
} 
[Тез®] 
РуБ11с у01а Сап АЯа Т%&етз_То Саг®() 
{ 


Ркодос® р1 = пем Ргодоас® { Ркоазсе тр 
РкодасЕ р2 = пем Ркодис® { Ргоаасетр 


1}; 

2}; 

// Добавить три товара (два из них одинаковы) 

Саке саг® = пеи Сак®(); 

сакё.АаатТфем (р1, 1); 

сакЕ.Ааатеем (р1, 2); 

саг®.Адатеем (р2, 10); 

// Проверить количество строк результата 

Аззеге.АгеЕЧиа1 (2, саг®.Ь1пез.Созре, "Икопд пимег оЕ 11пез 11 саг"); 
// Неверное количество строк в корзине 


| 


// Проверка правильности количества добавленных товаров 
Уаг р11Т1пе = саге .Т1пез.ИВете (1 => 1.Ргоаис®.Ргоаас®тр == 1) .Р1узь(); 
Уаг р211пе = сагЕ.Т1пез.Иреге (1 => 1.Ргоаас®.Ргоаасетр == 2) .Е1узЕ(); 
Аззеге.АгеЕдоа1 (3, р111пе.Опар®1еу); 
Аззеге.АгеЕаца1 (10, р211ре.ОцапЕ1 у); 

} 


[Тез] 

рур11с уо1а Сап Ве С1еагеа() 

{ 
СагЕ сакф = пем Саг® (); 
саг®.АааТеет (лем РкодосЕ (), 1); 
Аззег&.АгеЕаца1 (1, саге.1пез.Соппе); 
сак®.С1еаг(); 
Аззеке.АгеЕаоа1 (0, сакё.Г1рез.Созп®); 


} 


[Тезе] 

рУЮ11с уо1а Са1со1афез Тока1 Уа1ае Согкес®1у() 

{ 
Саг® саг® = пеи Сак®(); 
саг&.Ааатеет (пеи Ркоаас® { РкоансЕТЬ = 1, Рг1се = 5 }, 10); 
саг®.Ааатееп (пем Ркоаас® { Ркоаис® Тр =2, Рг1се =2.1М }, 3); 
саг .АЧЯТ®ет (рем Рко@асе { РгодисЕТЬ = 3, Рг1се = 1000 }, 1); 
Аззеге.АгеЕчиа1 (1056.3, саг®.СотрифеТота1Уа1ие()); 


} 


(Если вам незнаком синтаксис, то знайте, что Мв 2.1М сообщает компилятору С#, что это лите- 
ральное значение типа Зес1та1.) 
—_—_ 


С помощью синтаксиса С# 3.0 реализовать это поведение несложно: 


рур11с с1азз Саг® 
{ 
ре1уабе Ъ13%<Сах®Т1пе> 11пез = пеи 1156<СагЕТ1пе>(); 
рир11с 11186<СакЕТ1пе> ГШлпез { деф { хебагп 11пез.АзКеаЧОр1у(); } } 
риБ11с уо1а Ааатеем (Ркеодас® рго@ас®, 1пе чоаве1фу) 
{ 
// ЕзхзеОхОеЕаю1+() - расширяющий метод ГМО на ТЕпимега ле 
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уаг 11пе = 11пез 

.ЕР1хзЕОхреЕащ14 (1 => 1.Ргоаиас®. РтодасеТр == рхоаис*.РгодисЕТО); 
а (11те == по11) 
12пез.АЯЯ(пем СахЕЪЗпе { Ргодасе = ргодисе, Опапе1 у = саапафу }); 
е1зе 

11пе.Опцапе1еу += даапЕАу; 

} 
руБ11с Яаес1а1 СошрабеТота1Уа1ае () 
{ 

// $ит() - расширяющий метод ГТМО на ТЕпопегаЪ1е 

хееахп 11пез.5им(1 => 1.Ргобис®.Ргасе * 1.ОпапЕаеу); 
} 
рую11с \о19 СТеах () 
{ 


11пе$.С1еаг(); 


} 


Такой код обеспечивает успешный проход тестов Саг\Тез+з. Однако есть еще один 
момент, который следует учесть: посетители должны иметь возможность удалять эле- 


менты из корзины. Чтобы класс Са’ поддерживал удаление элементов, добавьте в него 
следующий дополнительный метод: 


руб11с уо1а Вепоуе!1те (РгодисЕ ргодисЕ) 
{ 

11пез.ВепоуеА11 (1 => 1.Ркодасе.РкодасетТр == ргодис+ .Ркодиасеть) ; 
} 


(Добавление теста для удаления элементов из корзины оставляется в качестве уп- 
ражнения для самостоятельной проработки.) 


На заметку! Обратите внимание, что свойство 11пез теперь возвращает свои данные в форме 
только для чтения. Это имеет смысл: ведь код на уровне пользовательского интерфейса не 
должен модифицировать элементы коллекции Т1пез напрямую, поскольку это позволит иг- 
норировать или нарушать бизнес-правила. Для обеспечения инкапсуляции необходимо, чтобы 
все изменения коллекции Т.1пез проводились через АР!-интерфейс класса Сагк. 


Добавление кнопок АДА фо са 


Вернитесь к частичному представлению /\1еиз/5ВагеЯ/РгодисЕ$ отаку. азсх и 
добавьте кнопку Ада 10 сам: 


<Ч1у с1азз="1ещ"> 
<р3><%= Моде1.Маме %></63> 
<%= Моде1.Безск1ре1ол %> 
<$ излпа (НЕт1 .ВедапЕоги ("АЯЯТоСате", "Саге")) { $%> 
<$= Нет. Наааеп ("Рхобасе тр") $%> 
<$= Нёт1.Н1Ядеп ("хееохпОтх1", 
УлеиСопЕехе . НЕЕрСопфехЕ .Бедаез+. 0х1 .РаВАпаОчцехку) $> 
<1проЕ вуре="зыЪи1е" уа1ае="+ АЯЯ +о саке" /> 
<$ } %> 
<64><%= Моде1.Рг1се.То5Ег1юа ("с") %></164> 
</а1\> 


Теперь приложение еще на один шаг приблизилось к возможности продавать товары 
(рис. 5.7). 
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Рис. 5.7. Кнопки АСЯ \ю саг 


Каждая из кнопок АО 10 сай передает с помощью НТГР-запроса РОЗТ соответствую- 
щий РГгоаосеТр действию АааТоСат+ класса контроллера по имени СатЕСопего11ехг. 
Обратите внимание, что Нещ1.Вед1пЕоги() по умолчанию визуализирует формы с ат- 
рибутом иеспоа, установленным в РОЗТ, хотя существует перегрузка этого метода, ко- 
торая позволяет специфицировать вместо этого метод СЕТ. 

Поскольку СагЕСопехо11ех не существует, щелчок на кнопке Ада фо сам приводит к 
возникновению ошибка в контейнере 1оС (Уа№е саппо! Бе пи!. Рагатщег пате: зегмсе 
(Значение не может быть по11. Имя параметра: зегу1се)}. Чтобы установить для кно- 
пок АДЧ 10 са“ черный цвет, понадобится добавить дополнительные правила в файл 
С$5$: 

ГОВМ { пага1т: 0; рада: 0; } 

РТУ.1еет ЕОВМ { ЕГТоае:х1оВе; } 

РТУ.1$еп ТМРОТ { 

соТог:Ие; Баскагоипа-со1ог: #333; Богаег: 1рх 30119 Раск; 
сигзог:ро1ртег; 


} 
Использование нескольких дескрипторов <Еогш> 


Возможно, вы уже заметили, что такое использование вспомогательного метода 
НЕи1.Вед1пРгоги() означает, что каждая кнопка Ада 10 са визуализируется в собст- 
венной маленькой НТМ!-форме <Еогт>. В сравнении с АЗРМЕТ \еБЕогтаз, где каждая 
страница допускает только один дескриптор <Еогт>, это может показаться странным 
и тревожным, однако не беспокойтесь — скоро все станет ясно. С точки зрения НТМГ 
нет никаких причин, по которым страница не могла бы иметь несколько (даже сот- 
ни) дескрипторов <Еогц> при условии, конечно, что они не вложены друг в друга и не 
перекрываются. 

Формально помещать каждую из этих кнопок в отдельный дескриптор <Еоки> не 
обязательно. Так почему рекомендуется поступать подобным образом? Дело в том, что 
каждая из этих кнопок должна инициировать НТТР-запрос РОЗТ с отличающимся на- 
бором параметров, а это проще всего сделать путем создания отдельного дескриптора 
<Еоги> для каждого случая. А почему здесь важно использовать запрос РОЗТ, а не СЕТ? 
Да потому, что согласно спецификации протокола НТТР запросы СЕТ должны быть 
идемпотентными (те. не вызывать нигде изменений), а добавление товара в корзину 
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определенно ее изменяет. В главе 8 вы узнаете, почему это важно, и что может случить- 
ся, если вы проигнорируете этот совет. 


Предоставление каждому посетителю 
отдельной корзины для покупок 


Для того чтобы кнопка Ада 10 сай работала, потребуется создать новый класс кон- 
троллера — СахСопехго11ех, оснащенный методами действий для добавления и уда- 
ления элементов из корзины. Но минуточку! О какой конкретно корзине идет речь? Вы 
определили класс Саг®, и пока это все. Еще нет никаких его экземпляров, доступных в 
приложении, и фактически пока даже не решено, как это будет работать. 


® Где хранить объскты Саге — в базе данных или в памяти веб-сервера? 


® Можно ли один экземпляр Сах® разделять между всеми, или же каждый посети- 
тель должен иметь отдельный экземпляр Саг+. А, может быть, новый экземпляр 
должен создаваться для каждого НТТР-запроса? 


Очевидно, что нужен такой экземпляр Саг®, который существует дольше, чем оди- 
ночный НТТР-запрос, так как посетители будут добавлять к нему объекты СагЕ1пез в 
последовательных запросах. И, конечно же, каждый посетитель нуждается в отдельной 
корзине, не разделяя ее с другими посетителями, которые делают покупки одновремен- 
но с ним; иначе наступит хаос. 

Естественный способ обеспечить такие характеристики — хранить объекты Саг® в 
коллекции Зезз1оп. При наличии предшествующего опыта работы в АЗРМЕТ (или даже 
в классическом АЗР) вы знаете, что коллекция Зезз1оп хранит объекты на протяжении 
всего сеанса браузера посетителя. По умолчанию се данные хранятся в памяти веб-сер- 
вера, но в файле меь.сопЁ1а можно сконфигурировать и другие стратегии хранения 
(в процессе, вне процесса, в базе данных ЗОЕ и ти.)}. 


Более аккуратный способ работы с хранилищем 
5е5$1оп, предлагаемый А$Р.МЕТ МУС 


До сих пор все, что обсуждалось о корзинах для покупок и $езз1оп, было очевид- 
ным. Но вы должны понимать, что несмотря на то, что в АЗРМЕТ МУС имеется множе- 
ство общих компонентов инфраструктуры (вроде коллекции 5езз1оп) со старыми тех- 
нологиями, такими как АЗР и АЗРМЕТ \/еБЕогтаз, в основу их использования положена 
совершенно другая философия. 

Разрешение контроллерам манипулировать коллекцией 5езз1оп напрямую, поме- 
щая и извлекая объекты эпизодически, как если бы Зезз1оп была крупной и доступной 
для всех глобальной переменной, увеличивает риск появления ряда проблем при сопро- 
вождении. Что, если контроллеры потеряют синхронизацию. когда один из них будет 
искать Зезз1оп ["Сагё"], а другой — Зезз1оп["_ сагЕ"]? Что, если контроллер будет 
исходить из того, что Зеззтог ["_сак®"] должно быть заполнено другим контроллером, 
а на самом деле окажется не так? Как насчет неудобства написания модульных тестов 
для кода, обращающегося к Зезз1ол, с учетом того, что для этого необходима имити- 
руемая или фиктивная коллекция Зезз1о1? 

В АЗРМЕТ МУС лучшим методом действий будет такой, который является чистой 
функцией его параметров. Под этим подразумевается, что метод действия считывает 
и записывает данные только в свои параметры, не обращаясь к НЕЕрСопеехе., Зезз1оп 
или любому другому состоянию, внешнему по отношению к контроллеру. Если достичь 
этого удалось (что обычно так, но не всегда), то затем можно установить ограничения 
на сложность контроллеров и действий. Это приводит к семантической ясности, кото- 
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рая обеспечивает понимание кода с первого взгляда. По определению такие автономные 
методы легко проверять с помощью модульных тестов, поскольку нет никакого внешне- 
го состояния, которое при этом необходимо эмулировать. 

В идеале методы действия должны получать в качестве параметра экземпляр Саг\, 
потому им не нужно беспокоиться о том, откуда берутся экземпляры. Это упрощает 
модульное тестирование: тесты смогут поставлять объекты Саг® действию, запускать 


его и затем проверять, какие изменения произошли в Саг®. Кажется, неплохой план 
действий. 


Создание специального средства привязки модели 


Как вы уже знаете, в АЗРМЕТ МУС имеется механизм, называемым привязкой моде- 
ли, который, помимо прочего, используется для подготовки параметров, передаваемых 
методам действий. Именно так в главе 2 мы получали экземпляр СиезфВезропзе, авто- 
матически выделенный из входящего НТТР-запроса. 

Это мощный и расширяемый механизм. Теперь вы узнаете, как создать специальное 
средство привязки модели, которое поставляет экземпляры, извлеченные из некоторого 
хранилища (в данном случае из коллекции 5езз1о1). Когда оно будет готово, методы 
действий легко смогут получать экземпляры Саг® в качестве параметра, не заботясь 
о том, как эти экземпляры создаются или хранятся. Добавьте в корень проекта Мерот 
следующий класс (формально он может находиться где угодно): 


рую11с с1азз СахЕМоде1В1таег ; 1Моде1В1адег 
{ 
ре1уабе сопзЕ зЕг1пд сагёбезз1опКеу = "_ саге"; 
риБ11с об)есЕ ВзпаМо@де1 (СопЕго11егСопеехе сопёго11еуСопеехе, 
Моае1В1191п9Сопфехе Ь1п91пчСопеехЕ) 


// Некоторые средства привязки модели могут обновлять 
// свойства существующих экземпляров модели. 
// Здесь это не нужно — оно служит только для применения 
// параметров метода действий. 
1Е (6109109 Соптехе.Моде1 != по11) 

ЕРгои пем 

Тпуа11ЯОрегае1опЕхсере1от ("Не удалось обновить зкземпляры"); 

// Вернуть объект сагЕ из 5ез51оп[] (создав его при необходимости) 
СагЕ саге {Саг®е) сопего11егСопфехЕ.НЕЕрСоптехе .Зез1оп[сагЕ5ез1опКеу]; 
1Е(сакЕ == по11) { 

саге = пеи Саг® (); 

сопЕтго11етСопеехе .НЕЕрСопеехе .Зезз1оп[сатЕ5езз1опКеу] = саге; 


й 


} 


тегакп саг; 


} 


Подробные сведения о привязке модели, а также о том, как встроенное средство при- 
вязки по умолчанию может создавать экземпляры и обновлять любой пользовательский 
тип .МЕТи даже коллекции таких типов, приводятся в главе 12. Пока достаточно знать, 
что СахЕМоде1В1п4ег представляет собой просто разновидность фабрики Сагт, которая 
инкапсулирует логику предоставления каждому пользователю отдельного экземпляра, 
хранящегося в коллекции Зезз1оп. 

В АЗРМЕТ МУС класс СагЕМоде1В1паетг не будет использоваться до тех пор, пока 
это не будет явно указано. Добавьте в метод Арр11саЁ1оп_5фагЕ() из файла С1офат. 
азах.сз следующую строку, назначив Саг{Моде1В1пдег в качестве средства привязки 
для использования там, где требуется экземпляр Сат{: 
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рготестей уо1а Арр11саЕ1оп З%ах® () 
{ 


// ... остальной код не изменяется ... 
Моде1В1п4етз .В1пдегз.АЯЯ (туреоЕ (СагЕ), пем СагЕМоде1Ватаекг()); 
} 


Создание СахЕСопЕго11ег 


Теперь давайте создадим СагЕСопегоЛег, полагаясь на специальное средство привязки 
модели для получения экземпляров Саг+. Начать можно с метода действия АдаТоСахе (). 


Тестирование: класс контроллера Саг+Соп+го11ег 


Класс контроллера под названием СахЕСопеско11екх пока не существует, но это не должно по- 
мешать проектированию и определению его поведения в терминах тестов. Добавьте в проект 
Тез новый класс СагЕСопего11ехТез+з: 


[ТезеЕ1хЕоте] 
раЮ11с с1азз СагхЕСопего11егТезез 
{ 
[Тез®] 
рир11с у014 Сап Ааа РгодисЕ То СакЕ() 
{ 
// Подготовка: установить имитируемый репозиторий с двумя товарами 
уаг поскРЕгоаисе$Вероз = пеи Моа.Моск<ТРгодисезВеро51+огу> (); 
уаг ргодоасе$ = пем бзузеем.Со11есЕ1о1$ .Сепег1с.11$Е<Ркодись> { 
рем РгоЧисЕ { РгодосеЕТЬ = 14, Маше = "МосЬ Адо АбобЕ Мо бЬ4па" }, 
реи Ргодисе { Ргодосетр = 27, Маме = "Тре Сотеду оЕЁ Еггогз" }, 
}; 
поскРЕОодосе$Бероз .Зегор (х => х.Ркодис\з) 
.Вебиагпз (ргодисе$ .АзОцегуаЬ1е ()); 
уаг саге = пем Сат® (); 
уаг сопего11ех = пем СагеСопего11ех (поскРго@дис®Вероз .ОБ]ес+); 


// Действие: попробовать добавить товар в корзину 
Веа1гесеТовопевези1е гези1е = 
сопфтго11ег.АдЯТоСаге (сагё, 27, "зомевесигп0Ог1"); 


// Утверждение 

Аззеге.АгеЕааа1 (1, саге.11пез.Соипь); 

Аззеге.АхгеЕдиа1 ("Те Сомеду оЁ Еггогз", саге.Т1пез[0].Ргодос*.Маце); 
Аззеге.АгеЕчиа1 (1, саге .14пез[0].ОцапЕ1ку); 

// Проверить, что посетитель перенаправлен на экран отображения корзины 


Аззете.АгеЕаиа1 ("Тпаех", гезо1е .Вопее\Уа1ез ["асЕ1оп"]); 
Аззетс.АгеЕадиа1 ("зомевесогп0От1", гези1е.Воике\уа1щез ["гебигрОг1"]); 


} 


Обратите внимание, что СатЕСопЕго11ег принимает ТРЕОЗИСЕ зВеро$1Фоку в качестве па- 
раметра конструктора. В терминах 10С зто означает, что СатсСопЕго11ет имеет зависимость 
ОТ ТРЕОоЧисЕ $Вероз1фохгу. Тест указывает, что СахЕ будет первым параметром, переданным 
методу АааТоСахе (). Этот тест также определяет, что после добавления запрошенного товара 
в корзину для покупок посетителя контроллер должен перенаправить посетителя на действие под 
названием Тпаех. 


На данном этапе можно также написать тест под названием Сап_Ветоуе Рхо@исф Екой Саг (), 
проверяющий возможность удаления товара из корзины. Это оставляется в качестве упражнения 
для самостоятельной проработки. 
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Реализация дааТоСаг и ВетоуеЕгкотСакЕ 


Чтобы решение было построено, а тесты успешно проходили, потребуется реализо- 
вать СагСопего11ет с парой довольно простых методов действий. Для этого достаточ- 
но лишь установить зависимость 10С от ТРГодисЕВероз1еогу (имея параметр конструк- 
тора этого типа), предоставить Саг как один из параметров методов действий и затем 
скомбинировать значения. применяемые для добавления и удаления товаров: 


риЮ11с с1аз$ СагеСопего11ег ; Сопего11ег 
{ 

ре1уафке ТРгодосезВеро51Еогу ргодисезВероз1огу; 

рур11с СакЕСопего11ех (ТРкодисеВероз1тогу ргодисезВероз1Когу) 

{ 
$515 .ргодисеВероз1фтогу = ргодосезВероз1фогу; 

} 

ру611с Вед1хесЕТоВоцееВези1{ АЯЯТоСаге (СахгЕ саге, ЗрЕ ргодасетр, 

зЕк1па гебагпОг1) 

{ 

РгоаисЕ ргодисЕ = ргодосеВероз1фоку.Ркодосев 
.Е1г5сОгоеЕаи1+ (р => р.РгодисЕТР == ргодосетЬ); 

саге.АдаТтем (ргодосе, 1); 
тебиги ВКед1кесЕТоАсЕ1оп ("Тадех", пем { гекихкпОт1 }); 

} 

роф11с Вед1гесЕТоБои®еВези1Е ВетоуеЕгомСаг* (СагЕ саге, 10% ргоа<осетр, 

зЕг1па гебогпОк1) 

{ 

РкоаисЕ ргодисЕ = ргодас&зВероз1{огу.Ргодисез 
„.Е1х5сОгреЕао1® (р => р.РгодисЕТЬ == ргодисетр); 

саге .Вепоуе11пе (ргодасе); 
тебигр Вед1гесЕТоАсетоп ("Тпдех", пем { гкефигпОх1 }); 


} 


Здесь важно отметить, что имена параметров АЯаТоСаг® и ВепоуеЕгопСат{ соответ- 
ствуют именам полей <Ё1е1а> в /У1емз/ 5ВагеЯ/Ргодисе$иттагу.азсх (те. ркодисЕ тр 
и гебигрОт1). Это позволяет АЗРМЕТ МУС ассоциировать с этими параметрами пере- 
менные формы входящего НТТР-запроса РОЗТ. 

Помните, что Вед1кесеТоАс®1оп () приводит к перенаправлению НЛТР 302^. Это за- 
ставляет браузер посетителя запросить новый ОБТ, в данном случае — /Сах+/Тидех. 


Отображение корзины 


Давайте подытожим, что было сделано в отношении корзины для покупок. 


® Определены объекты модели Саг\ и СагЕ1.1пе и реализовано их поведение. Всякий 
раз, когда метод действия требует Саг+ в качестве параметра, СахЕМоче1В1пдег 


автоматически подставляет корзину текущего посетителя, взятую из коллекции 
Зезз1оп. 


® Добавлены кнопки Ада 10 сам (Добавить в корзину) на экраны списка товаров, 
которые направляют к действию АЧЯТоСах* () контроллера СагЕСопего11ех. 


4 Такого же перенаправления можно добиться и вызовом метода Везропзе. Кед1гес® () в 


АЗРМЕТ \еБЕогилз; однако при этом не возвращается объект Аск1опвези1*, что затрудняет 
тестирование контроллера. 
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® Реализован метод действия АЧаТоСаг® (), который добавляет указанный товар в 
корзину посетителя и затем перенаправляет браузер на действие Тпдех контрол- 
лера СагЕСопего11 ег. (Действие Тпдех должно отображать текущее содержимое 
корзины, но пока оно не реализовано.) 


Запустите приложение и щелкните на кнопке АДА 0 са рядом с наименованием 
какого-нибудь товара. Результат показан на рис. 5.8. 
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Рис. 5.8. Результат щелчка на кнопке Ада 10 сай 


Не удивительно, что возникла ошибка 404 М1 Еоппа (не найдено), поскольку дейст- 
вие Тпаех контроллера СакЕСопфго11ег пока еще не реализовано. Это довольно про- 
стое действие, так как все, что оно должно делать — это визуализировать представле- 
ние, передавая Саге текущего посетителя и текущее значение гекигп0т1. Также имеет 
смысл наполнить У1емРафа ["СахгепеСафедогу"] строкой Саг\, чтобы в меню навига- 
ции ничего не выделялось. 


Тестирование: действие Тпаех контроллера СатЕСоп+хо11ех 


Как только проектное решение построено, его легко представить в виде теста. Учитывая 
то, какие данные это представление должно визуализировать (корзина посетителя и кнопка 
для возврата к списку товаров), давайте скажем, что будущее действие Тпдех контроллера 
СагёСопфго11ет должно установить Моде1 для ссылки на корзину посетителя, а также запол- 
нить У1емрафа ["хебахпОк1"]: 


[ТезЕ] 
руЮ11с уо14 Гпаех АсЕ1оп Вепдегз РеЁаи1Е \У1еи М1ЕБ Саге Апа вВебокпОг1 () 
{ 

// Установить контроллер 

СагЕ сагЕ = пем СагЕ (); 

СагЕСопего11ет сопего11етг = пем СагЕСопего11ег (пи11); 


// Вызвать метод действия 
УтемВези1е гезоЕ = сопЕго11ег.Тпаех (саге, "туВебогпОк1"“); 


// Проверить результаты 
Аззег®.Т3зЕтреу (кезо1.\У1еиМане); // Визуализировать представление по умолчанию 
Аззеге.Агебапе (саге, геза1{&.Улемрака .Моае1); 
Аззег{.АгеЕаца1 ("тмувебсогпОт1", гезо1®.У\У1емраха ["гебогпОк1"]); 
Аззеге.АгеЕаиа1 ("Сагь", гези1®.\У1еи Вафа ["СиггепеСафедогу"]); 

} 


Как всегда, сразу зто не скомпилируется, потому что еще нет метода действия Тпаех (). 
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Реализуйте простой метод Тпдех (), добавив новый метод в класс Саке Сопфго11ет: 


рую11с У1емВези1е Тпдех (СагЕ саг®, зЕу1та кебагпОгк1) 
{ 
У1емРаса["хергихи0т1"] = гебигп0г1; 
У1еирафа["СиггепеСакедогу"] = "Сагё"; 
гебагп Улем(сахг®); 


} 


Несмотря на то что этот код обеспечит прохождение теста, понадобится еще опреде- 
лить шаблон представления. Щелкните правой кнопкой мыпти внутри метода Тпдех () 
и выберите в контекстном меню пункт Ада Мем/ (Добавить Представление). В открыв- 
шемся окне отметьте флажок Сгеа а зтопоу 1уред мемм (Создать строго типизирован- 
ное представление) и в раскрывающемся списке Ме\м даа с!а$$ (Класс данных пред- 
ставления) выберите Ропа1пМо4е1 .Ер11ез.Саге. 

После отображения шаблона поместите в заполнители <азр:СопеепЕ> разметку для 
визуализации экземпляра Саг\, как показано ниже: 


<азр:Сопеепе СопфепЕР1асенНо19егТр="Т1{1еСопеепе" хипак="зегуег"> 
ЗрогЕ$5еоге : Уойг СагЕ 
</азр:Сопеепт> 
<азр:Соптепе СоптепЕР1асеНо14егтТр="Ма1пСопЕепе" гипас="зегуег"> 
<в2>Уойг сагЕ</р2> 
<тар1е и19="90%" а11ап="сепеег"> 
<Енеад><Ег> 
<ЕВ а119т="сепеег">Оцапе1еу</еЬ> 
<ЕВ а119п="1еЕе">Теен</еь> 
<ЕВ а119т="у1оВе">Ре1се</ > 
<ЕР а119п="г1аВе">5иреота1</еЬ> 
</Ег></ЕВеа4> 
<ЕБодау> 
<% ЕогеасВ (уаг 11пе 1п Моае1.11пез) { %> 
<Ег> 
<ЕЧ а119т="сертег"><%= 11пе.ОцапЕ1еу %></+9> 
<ЕЯ а119п="1еЁЕ"><%= 11пе.Ркгодис®.Маше %></%9> 
<Е9 а119п="х19Не"><%= 11пе.Ргодисе.Рг1се.Тобек1та ("с") %></Е49> 
<ЕЯ а11ап=" клаве"> 
<%= (11пе.ОцапЕ1у*11пе.Ргодисе.Ру1се) .Тобет1та ("с") $> 
</Еа> 
</Ег> 
<$ } %> 
</Ероду> 
<ЕЕБоо><Ет> 
<ЕЯ со15рап="3" а11дп="г1аре">Тофа1:</Е9> 
<{а а11ап=" глав" > 
<%= Моде1.СоприееТота1Уа1ие () .ТозЗЕк1та ("с") %> 


</Еа> 
</Ет></ЕЕооф> 
</тар1е> 
<р а1191="септех" с1азз="асЕ1опВаееоп$"> 
<а ргеЕ="<%= Ни1.Епсоде (У1емаха["гефагр0тг1"]) %>">СопЕ1пие зВорр1па</а> 
</р> 


</азр:Сопеепф> 


Пусть кажущаяся сложность этого шаблона представления вас не пугает. Он всего 
лишь проходит по коллекции Моде1 .14пез и выводит каждую строку в НТМГ-таблицу. 
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Кроме того, он добавляет удобную кнопку Сопйпие эПорртд (Продолжить покунку}, ко- 
торая перенаправляет посетителя обратно на страницу товаров, где он был ранее. 

Каков же результат? Теперь вы имеете работающую корзину для покупок, показан- 
ную на рис. 5.9. В нее можно добавить элемент, щелкнуть на кнопке Сомтие зпорро, 
добавить другой элемент итд. 
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Рис. 5.9. Корзина для покупок в действии 


Чтобы облагородить внешний вид, понадобится добавить несколько правил С$$ в 
/Сопфепе/зЕу1ез.с35: 


Н2 { паго1п-бор: 0.3Зеи } 

ТЕООТ ТР { Богдетг-кор: 1рх доетеЯ дгау; Еопе-мелаве: Бота; } 

„.асетопВиесопв А { 
Еопе: .Вет Аг1а1; со1ог: М1е; паго10: 0 .5ет 0 „5ещ; 
Техе-десога®1оп: попе; рада1та: .15ет 1.5ет .2ем 1.5еп; 
Баскагоипа-со1ог: #353535; Рогдег: 1рх во114а ю1аск; 

} 


Наблюдательный читатель заметит, что в приложении пока еще нет никакой воз- 
можности оформить и оплатить заказ. Скоро такая возможность будет добавлена, но 
сначала необходимо добавить еще пару средств корзины для покупок. 


Удаление элементов из корзины 


Предположим, что посетитель обнаруживает, что ему не нужно столько футбольных 
мячей, сколько находится в его корзине для покупок. Как их удалить оттуда? Чтобы реа- 
лизовать поведение удаления, модифицируйте /У1еиз/СатЕ/Тпаех .азрх, добавив кноп- 
ку Ветоуе (Удалить) в новый столбец каждой строки СахЕТ1 пе. Поскольку это действие 
будет вызывать постоянный побочный эффект (удаляя элемент из корзины), должна 
использоваться форма <Еоги>. которая отправляет данные через запрос РОЗТ, вместо 
вспомогательного метода Нёт1 .Асф1опр тик (), который инициирует запрос СЕТ: 
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<%$ ЕогеасВ (уаг 11пе 1п Моде1.Т1тез) { %> 
<Ек> 
<{а а11ап="сепеег"><%= 11ре.ОцапЕ1у $></Е9> 
<Еа а119п="1еЁе"><%= 11пе.Рго@ас®.Мацще %$></54> 
<Еа а119т="г1аВе"><%= 11пе.Ргодис®.Ру1се.Тобег1иа ("с") $%$></6а> 
<Еа а119п="к1аве"> 
<%= (110е.Опаре1у*11пе.Ргоаис®е.Рг1се) .ТобЕг1иа ("с") %> 
</Е9> 
<+а> 
<% из4па (НЕи1 .ВедапЕокт ("ВепохеЕтотСат®", "Сах*")) { $> 
<%= Нём1 .Н1адеп ("РгодосеТО", 11пе.Ргоаисе.Рходасетр) %> 
<3%= Нёт1.Н1@аЗеп ("хефкохпОх1", У1емдафа["гееатпи0Ох1"]) $> 
<1приЕ Еуре="зиЬт1е" уа1ае="Ветохе" /> 
<$ | %> 
</&9> 


В идеале также следует добавить пустые ячейки к строкам заголовка и нижнего 
колонтитула, чтобы все строки имели одинаковое количество столбцов. В любом слу- 
чае, удаление товаров из корзины будет работать (рис. 5.10}, так как метод действия 
КепоуеЕтойСат® (саге, ргодисЕТа, гебогпОт1) уже реализован, а имена его парамет- 
ров соответствуют именам полей только что добавленной формы <Гогп> (ще. Ркодисета 
и гебигпОт1). 
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Рис. 5.10. Кнопка Ветоуе корзины для покупок в действии 


Отображение итоговой суммы 
по корзине в строке заголовка 


Приложению Эро Юге сейчас присупти две основных проблемы, которые касаются 
удобства использования. 


® Посетители не имеют понятия о содержимом своей корзины, пока не обратятся к 
экрану, отображающему корзину. 


® Посетители не могут попасть на экран содержимого корзины (те. к оформлению 
заказа) без добавления в нее хоть какого-нибудь товара! 


Для решения обеих проблем давайте добавим на мастер-страницу приложения кое- 
что еще — новый виджет, отображающий краткую итоговую информацию о текущем 
содержимом корзины и предоставляющий ссылку на страницу отображения содержи- 
мого корзины. Реализация этого виджета похожа на реализацию виджета навигации 
(т.е. в виде метода действия, вывод которого можно включить в /\У1емз /51{е.Мазтехг). 
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Однако на этот раз все будет намного проще, и это в очередной раз доказывает, что с 
помощью НЕт1 .ВепдегАс® Топ (} виджеты реализуются легко и быстро. 
Добавьте в класс СагЕСопЕго11ег новый метод действия по имени Зиттаху (): 


риб11с сТаз5 СахЕСопеко11ехк : Сорего11ег 

{ 
// Оставить остальную часть класса без изменений 
Риб11с У1еиВези1Е Зиштаку(СакЕ сагк+) 
{ 


хебикп У1ем (сак®); 


} 


Как видите, метод довольно прост. Необходимо лишь визуализировать представле- 
ние, отобразив текущие данные корзины, чтобы представление могло ноказать итого- 
вую сумму. Модульный тест для этого поведения написать очень легко. и по причине 
простоты он рассматриваться не будет 

Затем создайте шаблон частичного представления для виджета. Щелкните правой 
кнопкой мыши внутри метода биттагу() и выберите в контекстном меню пункт АЧа 
\Лем (Добавить представление). В открывшемся окне отметьте флажки Сгезе а рагйа 
мем (Создать частичное представление) и Сгеае а Нопоу Туре мем (Создать стро- 
го типизированное представление}, а в раскрывающемся списке Мем/ Чата са$$ (Класс 
данных представления) выберите класс Рота иМоде1 .ЕрЕ1е1ез.Саг+. Добавьте следую- 
щую разметку: 

<$ 1Е (Моае1.Глпез.СопрЕ > 0) { %> 

<О1у 19="саке"> 
<зрап с1азз=“"сар®1оп"> 
<Б>Уоитг сакё:</Б> 
<%= Моае1.Глпез.5им(х => х.ОпапЕ16у) %> 1{ей(5), 
<$= Моде1 .СотрасеТота1Уа1е () .То5Етх1па ("с") %> 
</зрап> 
<%= Нп1.Асс1топт1 ок ("СНеск обе", "Тиаех", "Сакк", 
пем { гебогкпОх1 = Кечиезе.0к1.РаЕНАпаОцеку }, по11)%> 
</а1х> 


Для подключения виджета к мастер-странице добавьте в /У1емз/5Вагед/$лее.Мазеехг 
следующие строки: 
<1у 19="реадег"> 
<% 1Е(! (УзеиСопеехь .Сопёго11ех 1$ Меьот.СопЕко11егс. СахЕСопЕхо11 ег) ) 
Нем .ВепдекАсЕ1оп ("Зиштаку", "Сакф"); %> 
<Ч1у с1азз="{161е">5РОВТ$ УТОВЕ</@1ху> 
</ату> 


Обратите внимание. что в коде для определения визуализируемого в данный мо- 
мент контроллера используется объект У1емСопеехЕ. Когда посетитель находится в 
СагЕСопего11ек, виджет итоговой суммы по корзине скрыт, поскольку бессмысленно 
иметь ссылку на страницу оформления заказа, если посетитель уже находится на ней. 
Аналогично, коду /У1ечз/СакЕ/5иттаку.азсх известно, что если корзина пуста, ника- 
кого вывода генерировать не нужно. 

Помещение такой логики в шаблон представления — максимум того, чго можно по- 
зволить; любую более сложную логику лучше реализовать посредством флага, устанавли- 
ваемого контроллером (который впоследствии можно проверить и предпринять соответ- 
ствующие действия). С другой стороны, зто личное дело разработчика. Предел сложности 
логики, помещаемой в контроллер, каждый должен определять самостоятельно. 
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Теперь добавьге один или более злементов в корзину. Полученный результат должен 
быть похож на показанный на рис. 5.11. 
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Рис. 5.11. Итоговая сумма по тележке визуализируется в строке заголовка 


Уже выглядит неплохо! И будет выглядеть еще лучше, когда вы добавите несколько 
дополнительных правил в /Сопеепе/зЕу1ез.с55: 


РТУ#сатЕ { Е1оа®:г19ЪЕ; 
паго1п: „ве; 
сотох: 511уегЕ; 
фаскакоипа-со1ог: #555; 
раЯ91лта: „.5ет .5ет .5ем 1еш; } 
РТ\У#сакг® А { сехе-десохаЕ1оп: попе; 
рааалпа: „.4ем 1ещ .4ем 1ещ; 
11 пе-релаНе:2.1ещ; 
пага1п-1еЕе: „.эем; 
фаскагоип-со1ог: #333; 
со1ог: Ее; 
фогаег: 1рх зо11А Б1аск; ) 
РТУ#саг® ЗРАМ.зиптаку { со1ог: ИБлее; } 


Теперь посетители могут видеть, что находится в их корзине, вдобавок стало вполне 
очевидно, каким образом попасть из любого зкрана списка товаров на зкран. отобра- 
жающий содержимое корзины. 


Отправка заказов 


Настало время заняться разработкой последнего средства приложения Зрог ге, 
ориентированного на заказчика: оформления заказа. Оно относится к предметной об- 
ласти, так что придется добавить немного кода к модели предметной области. Покупа- 
телю необходимо предоставить возможность указать сведения о доставке, которые за- 
тем проверить каким-то разумным способом. 

На данном этапе разработки приложение Зрогоге будет просто отправлять детали 
оформленного заказа администратору сайта по электронной почте. Пока что нет необ- 
ходимости помещать информацию о заказе в базу данных. С учетом того. что в будущем 
это может поменяться, упростим изменение поведения, реализовав абстрактную служ- 
бу отправки заказов ТОгаег5ои1 Е ег. 
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Расширение модели предметной области 


Начнем с реализации класса модели для сведений о доставке. Добавьте новый класс 
в папку ЕпЕ1Е1ез проекта Роща1пМоде1 и назовите его $5 1рр1иарека+ 13: 


папезрасе Пома1иМоде]1 .Ете1е1е$ 
{ 
ру511с с1азз 5№1рр1п90ефа11$ : ТРабаЕгкогТиЕо 
{ 
руБ11с зЕг1па Маше { деф; зеф; } 
риБ11с зЕу1па Г1пе1 { деф; зе; } 
руБ11с зЕт1та Г1пе2 { че; зеф; ) 
риб11с 5Ег1па Г1пеЗ { деф; зеф; } 
руБ11с зЕк1иа С1еу { деЕ; зе; } 
риую11с зЕг1па Эсаее { деф; зе®; } 
рою11с эег1па 74р { деф; зе®; } 
рир11с зЕг1иа Социеку { де; зек; } 
ри11с Боо1 С1ЕЕМгар { деЕ; зе; } 
РОБ11с зЕг1па 113 [56Е109 со1ошпМаше] // Правила проверки достоверности 


{ 


чеё { 
ТЕ ((со1оиоМаше == "Маме") && зЕе1ра. ТзМа1 1ОгЕпреу (Маце) } 
хебого "Р]еаз пёег а папе"; // Необходимо ввести имя 
ТЕ ((со1аипМаше == "Т1пе1")} && 3119. 13Мо1 1ОтЕшруу (Т1пе1) ) 


тебаги "Р]еазе епеег ЕПе ЕАгзЕ аагезз 11пе"; 
// Необходимо ввести первую строку адреса 

ТЕ ((со1ошпМаше == "С1фу") && $109. 15№211ОгЕпреу (сту) } 

гееаги "Р1еазе епфег а с1%ку папе"; // Необходимо ввести город 
1Е ((соТошпМаше == "Зфафе") && ЗЕг1па. 15М№11ОгЕпреу (5+а*е) } 

тегоги "Р1еазе епеег а зфаее папе"; // Необходимо ввести штат 
1Е ((со1ТоппМаше == "Соупеку") && зЕг1 па. 15М№о11ОгЕтреу (Соопеку) ) 

геригп "Р1еазе епеег а соопЕку раме"; // Необходимо ввести страну 
хебоги 0011; 


} 
РУБ11с зЕг1п9 Егког { деЕ { гебага по!1; } } // не требуется 
} 
} 


Как и в проекте из главы 2. правила проверки достоверности определяются с ис- 
пользованием интерфейса ТРафаЕгкогти[о, который автоматически распознается и со- 
блюдается средством привязки модели в АЗРМЕТ МУС. В этом примере правила очень 
просты: ряд свойств не могут быть пустыми — вот и все. Можете добавить собственную 
логику для определения действительности каждого свойства. 

Это простейший из нескольких возможных способов реализации в АЗРМЕТ МУС про- 
верки достоверности серверной стороны, хотя ему присущ ряд недостатков, о которых 


вы узнаете в главе 11 (там же будут рассмотрены некоторые более сложные и мощные 
альгернативы). 


—— 
Тестирование: сведения о доставке 


Прежде чем дальше расширять класс $В1рр1парета11, понадобится спроектировать по- 
ведение приложения, используя тесты. Каждый экземпляр сахе должен содержать набор 
561рр1п90ефа113 (поэтому $1 ррло9рета11з должно быть свойством СакЕ)}, причем свой- 
ство 551рр1парефа113з изначально должно быть пустым. Выразите это проектное решение, 
добавив несколько тестов к СагЕТезез: 
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[ТезЕ] 

р0611с уо1а СакЕ $51рр1п9_Рефа11з Зак _Етруу () 

{ 
СагЕ саг = пем Саг® (); 
564рр1п90ефа113 а = саг®.561рр1па0ефа1.13; 
АззегкеЕ. [5№211 (4.Мапе); 
АззегЕ. т3М№11 (а.Г1пе1); Аззек®. Тз№11 (9.Г10е2); Аззеке.15М№11 (а.11пе3); 
Аззеге.13№11 (9.С1у); АззекЕ. 13№11 (9.55аёе); Аззек®.1зМ№11 (@.Соцпегку); 
Аззегке. Т5№11 (9.71р)}; 

} 


[Тез%] 
роБ11с уо1а СагЕ Мое 61ЕЕМгаррейд_Ву_ПБеЁао1* () 
{ 


СакЕ сакЕ = пем Сак®(); 
Аззег® .ТзЕа1зе (саг® .5Ъ1рр1п90ета11$.С1ЕЕИкар); 


} 


Если не считать ошибки компиляции ‘ВотайМоде!.ЕтННез.Саг! 4оез поЁ сотат а аей- 
пйюп ог ‘ЭЫррторе{айз’ (рота1иМо@е1 .ЕпЕ1Е1ез.СагкЕ не содержит определения 
ЗВ1рр1парефа11 3), эти тесты должны проходить успешно, потому что они соответствуют по- 
ведению инициализации объектов С# по умолчанию. Тем не менее, иметь эти тесты стоит — они 
гарантируют, что никто нечаянно не изменит этого поведения в будущем. 


Чтобы удовлетворить проектное решение, выраженное с помощью предыдущих тес- 
тов (те. каждый СагЕ должен иметь набор 5111р1п90ефа113). модифицируйте класс 
СатЕ следующим образом: 

руБ11с с1азз СагЕ 


{ 


релуаее Г1з&<СагЕГите> пез = пем 113<СакЕЁР1пе> (); 

рию11с 1113 <СакЕТГ1пе> Г1пез { её { гебого 1пез.АзВеааОп1у(); } } 
ркзуаЕе $Р1ррапаОефа11$ зЬ1рр1парефа115$ = пем 5Ь14ррапареа115 (); 

РУЬ11с $Р1ррупарефа11$ $1ррапарефа11$ { де { гебакп зР1рр1пареЕа115; } 


// ... остальная часть класса не изменяется ... 


} 


Это и все изменения модели предметной области. Теперь тесты будут компилиро- 
ваться и успешно проходить. Следующая задача — использование обновленной модели 
предметной области на новом экране оформления заказа- 


Добавление кнопки СВеск Оц{ Мом 


Возвративитись к представлению Тпдех корзины, добавьге кнопку Спеск ОШ Мом 
(Оформить заказ). которая выполнит навигацию к действию по имени СпескоцЕ 
(рис. 5.12): 


<р а!19п="сепфег" с1аз5="ас1опВоЕ®опз"> 


<а НтеЕ="<%= НЕТ .Епсоае (У1емрафа ["хебако0хг1"]) %>">Сопе1тое зВорр1п9</а> 
<3= Н1.Асвтоп ак ("СРесКк опе пои", "СвескоОце") $> 
</р> 


</азр:СопеепЕ> 
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Рис. 5.12. Кнопка СПеск оц пом 


Приглашение покупателю ввести сведения о доставке 


Чтобы сделать ссылку СПесКк о\{ пом! рабочей, в класс Сакебопего11 ег потребуется 
добавить новое действие СпескОи+. Все, что оно должно делать — это визуализировать 
представление, которое будет формой сведений о доставке (551 рр1п90ееа115): 


[АссереУетрз (НеЕрУетЬз .Се®)] 
ро611с У1еиВези1 СБескОс{ (СагЕ саг®) 
{ 

тееаги У1ем (саге .5В1ррлпа0ета113); 
} 


(Этот метод ограничен ответами только на запросы СЕТ. Причина в том, что скоро 
у нас появится другой метод, соответствующий действию СВескоок, который будет от- 
вечать на запросы РОЗТ.) 

Добавьте для только что созданного метода действия шаблон представления (строго 
типизированный или нет — значения не имеет) со следующей разметкой: 


<азр:Сопеепе СопеепЕР1асено1аегтро="Т1&1еСопеепе" гирак="зегуетг"> 
Зрокез5фоге : Сеск оц 
</азр:СопеепЕ> 
<азр:Сопеепе СопеепЕР1асено1аегТр="Ма1юСопеепе" гора+="зегуег"> 
<в2>СВеск об пом</Б2> 
Р1еазе епфег уойт 9ефа113, апа ие'11 $В1р уопе 90093 г1аВЕ амау! 
<% и51п9 (НЕм1 .ВедлоЕоги()} { $%> 
<В3>561р 60</р3> 
<@1у>Мате: <%= НЕ] .ТехеВох ("Маше") $%></д4у> 
<В3>Адагезз</1в3> 
<Члу>1 Аше 1: <%= НЫт1.ТехеВох ("ТГ4пе1") %></а1у> 
<@1у>Т1пе 2: <%= Ни] .ТехЕВох ("Т4пе2") %></а1л> 
<91У>Г1пе 3: <$%= Н\ып1 .ТехеВох ("Г4реЗ"} %></алу> 
<Ч1У>С1еу: <%= Ни] .ТехЕВох ("С1еу") $></а1у> 
<блу>5фафе: <5= НЕ] .ТехЕВох ("5фафе")} %></91у> 
<91%>21р: <%= НЕшТ.ТехеВох ("71р") %></а1у> 
<91%>Соипехгу: <%= Н&и1 .ТехеВох ("Соопеку"} %></а1у> 
<63>Оре1оп$</63> 
<%= Нет .СрескВох ("С1ЕЕИгар") %> СЛЕ гар ЕВезе 1%епз 
<р а119т="сепЕег"><1прие фуре="зири1е" уха] ="Сотр1ефе огдехк" /></р> 
<$ } %> 
</азр:СопбепЕ> 


Результат показан на рис. 5.13. 
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Рис. 5.13. Экран сведений о доставке 


Определение компонента 10С для отправки заказов 


При отправке посетителем формы обратно на сервер некоторый код метода действия 
мог бы посылать детали заказа в сообщении злектронной почты через ЭМТР-сервер. 
Несмотря на удобство такого подхода, с ним связаны три сложности. 


® Возможность изменения. Возможно, в будущем зто поведение потребует- 
ся изменить, чтобы детали заказов сохранялись в базе данных. Если логика 
СахЕСопего1Тег будет перемешана с логикой отправки электронной почты, зто 
может оказаться затруднительным. 


® Возможность тестирования. Если АР -интерфейс ЭМТР-сервера не спроектиро- 
ван с учетом тестируемости, подставить имитированный ЭМТР-сервер во время 
модульного тестирования будет сложно. В резульгате либо не удастся написать 
модульные тесты для СъескОо* (), либо тесты должны будут посылать реальные 
злектронные письма через реальный 5МТР-сервер. 


® Возможность конфигурирования. Нужен какой-нибудь способ конфигурирования 
адреса 5МТР-сервера. Это можно сделать разными способами, но как сделать зто 
аккуратно, не изменяя соответствующим образом средства конфигурации, если 
позже понадобится перейти на другой серверный продукт ЭМТР? 


Подобно многим другим проблемам, все зти сложности могут быть устранены 
введением дополнительного уровня абстракции. Для зтого определим интерфейс 
ТОгдегбо т ЕЕег, который будет компонентом 1оС, ответственным за отправку оформ- 
ленных и проверенных заказов. Создайте новую папку Зег\1сез? в проекте Рота1иМоде1 
и добавьте в нее следующий интерфейс: 


5 Хотя этот интерфейс и назван службой (зегясе), это не значит, что он должен быть веб-служ- 
бой (\меЪ зегсе). К, сожалению, здесь мы столкнулись с конфликтом терминов: разработчики 
АЗРМЕТ привыкли называть “службами” веб-службы АЗМХ, в то время как в контексте оС 
и предметно-управляемого проектирования под службами подразумеваются компоненты, 
которые выполняют нужную работу, но не являются объектами сущностей или значений. 
В данном случае путаницы возникать не должно, поскольку интерфейс тОгаегзоби1 еек 
мало чем напоминает настоящую веб-службу. 
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папезрасе Попма1пМо@е!1 .5егку1сез 

{ 
риь11с 1пеегЁЕасе ТОгдегборитеЕек 
{ 


014 Зибт1ЕОтдег (Саг® саг®); 


} 


Теперь это определение можно использовать для написания остальной части дейст- 
вия СВескОце без компиляции СагЕСопего11ег с мельчайшими деталями действитель- 
ной отправки электронной почты. 


Завершение разработки класса СахЕСопЕго11ег 


Для завершения разработки класса СагЕСопеко11ет понадобится установить его 
зависимость от интерфейса ТОгдег5ицьта ееег. Обновите конструктор СакЕСопеко11ех 
следующим образом: 


рг1уаее ТРходисезВероз1Когу ргодисЕВеро$1огу; 
рх1уабе тОгдекЗоби1ЕЕек охдегбиаБилефегк; 
руБ11с СагЕСопеко11ех (ТРЕОЧисЕ$Вероз$1оку ргоаисЕ$Вероз1оку, 
ТОгЧег5чЬт1Е ег огдекЗаЪи: Ефег) 
{ 
515 .ргодисезВероз1фогу = ргоаосезВероз1®оку; 
515. окдег$аБи1 Ефек = охаекЗиьлаЕЕег; 
} 


—_ 
Тестирование: обновление тестов 


В настоящий момент скомпилировать решение не удастся, пока не будут обновлены модульные 
тесты, ссылающиеся на СаеЕСопего11ек. Причина в том, что теперь его конструктор принима- 
ет два параметра, а в коде тестов осуществляется передача только одного. Обновите все тесты, 
в которых создается экземпляр СахЕСопего11ек, указав значение по11 на месте параметра 
огдегборт1 Ефек. Например, вот как нужно изменить Сап_АЧа РгодосеТо Сакгк(): 


уаг сопего11ег = пем Са Сопегко!1ег (посСКРЕОбисЕзВероз.ОБ]есе, по11); 
После этого тесты должны проходить. 
м 


—— 
Тестирование: отправка заказа 


Теперь вы готовы определить поведение перегрузки РОЗТ метода Снескоц+ () с помощью тес- 
тов. Если пользователь отправляет либо пустую корзину, либо пустые сведения о доставке, то 
действие СВескОче () должно просто повторно отобразить свое представление по умолчанию. 
Заказ может быть отправлен через ТОтаег$ Би ЕЕег и визуализирован другим представле- 
нием по имени СошрТетеа только в том случае, если корзина не пуста и сведения о достав- 
ке корректны. Кроме того, после отправки заказа корзина для покупок посетителя должна быть 
опустошена (иначе возникает риск непреднамеренной повторной отправки заказа}. 

Эти проектные решения выражаются следующими тестами, которые понадобится добавить в 
СагЕСопЕго1ТегТезев: 

[Тезе] роБ11с уо19а 


бир ЕЕ119_Огдег И1ЕВ М Т4пез 215р1ауз_ПРеЁао1е \У1еи И1ЕВ Еггог () 
{ 


// Нодготовка 
Саг®Сопего11ек сопеко!Легк = пем СахСопеко1Тек (по11], по11); 
Сакф саг = пем Саг® (); 
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// Действие 
уаг гезо1е = сопего11ег.СВескО<е (саг®, пем ЕогиСо11есе1оп ()); 


// Утверждение 
Аззеге. Т5ЕтрЕу (гези1®.\/1емМаще); 
Аззегф. 15Еа1зе (тезо1.У1емрБафа.Моае15афе.т5\Уа1194); 
} 
[Тез] роЮ11с ухода 
Зори ЕЕ11п9 ЕшрЕу_$61рр1п9 Реба11з_ [015р1ауз ПеЁаи1 У1ем И1ЕБ Егкгог () 
{ 
// Подготовка 
СагЕСопЕго11ех сопЕго1Т1ег = пем СахЕСопеко11ег (по11, по!1); 
СагЕ саг = пем Саг®(); 
саге. АЧаТЕеп (пех Ргодос® (), 1); 


// Действие 
уаг гезо1Е = сопфго11ег .СрескоОчЕ (сах, пем ЕогтСо11есетоп { 
{ "Мапе " й "т" } 


р: 


// Утверждение 
Аззете. ТзЕшреу (гези1е .У1еМаше) ; 
Аззеткф. 15Еа15е (гези1е .\У1емПафа.Мо@е15аее.Т$\а11а); 
} 
[ТезЕ] рор11с уо1а 
\Уа11а Отаег боез_То бобилЕф ег Апа_015р1ауз_Сотр1ебея У1ем () 
{ 


// Подготовка 
уаг поск5ори1Ефег = пем Моа.Моск<Тогаетбобил Е ек> (); 
Са Сопехо!1ег сопёго!1ехк = пем СагЕСопеко11ех (по1], поскбобитЕЕег.ОБ)ес®); 
СатЕ саг® = пем Сагк®(); 
саге .Адатфем (пем Рго@осе (), 1); 
хат Еогибафа = пем ЕКотиСо11есе1оп { 
"Маше", "5феуе" }, { "Т4пе1", "123 Му 5Етеее" }, 


"Т1пе2", "МуАгеа" }, { "ГлпеЗ", "" }, 
"21р", "12ЗАВСОЕЕ" }, { "Соцпеку", "Рак Еагк амау" }, 


{ 
{ 
{ "Су", "МуС1Еу" }, { "5Зфабе", "боще кафе" }, 
{ 
{ 


"СТЕЕИгар", Роо1.Ткиебетаюа } 
}; 
// Действие 
уаг гезо1 = сопЕго11]ет.СБескоОчЕ (сакЕ, Еогирава); 


// Утверждение 

АззегЕ.АгеЕаоа1 ("Сопр1ефей", гезо1+.\У1емМапе) ; 
поск5ириз ЕФег.Уек1Еу(х => х.бори1ЕОгаег (саг®)); 
Аззеге.АгеЕаоа1 (0, саг®.ТГ1пез.Сопо®); 


Чтобы реализовать перегрузку действия СВескоОч{ для запросов РОЗТ и удовлетворить 
условия предыдущих модульных тестов. добавьте в СагЕСорего11ег еще один метод: 


[АссеркУетьз (НЕЕрУегЬз$ .Роз%) ] 
руб11с У1емВезо1Е СБескО<® (СакЕ сакЕ, ЕогиСо11ес1оп Ёогм) 
{ 
// Пустые корзины отправлять нельзя 
1Е (сах .Г1пез.Соти® == 0) { 
Моде15тафе .АдаМоае1Еггог ("Саге", "богку, уопгк саг 13 епр®у!"); 
теЕокп У1лем(); 
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// Вызвать привязку модели вручную 
1Е (Тгу0рдаеемо@е! (саг® .5В1рр1п90ефа11з, Еоги.ТоУа1иеРгоу1аехк()}} { 
огаегбоби1 Е ег. боби1Огаег (саг); 
сагЕ.С1еакг(); 
гебоки У1ем ("Сопр1ефеа"); 
а // Что-то было не так 
хебаки У1ем(); 

} 

Когда этот метод действия вызывает Тгу0рдафееМоде1 (), система привязки модели 
инспектирует все пары “ключ/значение” в Еогт (они извлекаются из входящей коллек- 
ции Ведиез® .Коги, в которой хранятся имена текстовых полей и значения, введенные 
посетителем) и использует их для заполнения соответствующим образом именованных 
свойств саге. 561рр1о90ефа113з. Этот тот же самый механизм привязки модели. кото- 
рый поставляет параметры методам действий, с тем лишь отличием, что здесь он ини- 
циируется вручную, так как саге .551рр1п90ефа113 не является параметром метода 
действия. Более подробные сведения об этой технике, включая использование префик- 
сов для работы с конфликтующими именами, будут даны в главе 11. 

Также обратите внимание на метод АЧМоде1Еггог () , позволяющий регистрировать 
любые сообщения об ошибках, которые будут отображаться посетителю. Реализацией 
отображения таких сообщений мы займемся чуть позже. 


Добавление фиктивного средства отправки заказов 


К сожалению, в нынешнем виде приложение не сможет работать, потому что кон- 
тейнеру 1оС не известно, какое именно значение передать в параметре зоб еек кон- 
структора СагЕСопего11ехк (рис. 5.14). 
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СЕ СтОКВ Евг вия Ветаче Е ксеруст. Сел огевие сотрогеи"Сапсоуетуие 85 8083 Зеса-пелоаь лю затегев 
саптользх в лаНор ге тропа берелоегияа. 


Рис. 5.14. Сообщение об ошибке М/пазог, которое он выдает, 
если не может разрешить зависимость 


Для решения зтой проблемы определите класс ГакеОгдегбобюаееег в папке 
/Зегу1сез проекта Рота1пМоае1: 


патезрасе Рома1пМо@е1 .5егу1сез 


{ 
руб11с с1азз Еакед0гаегборт1Е$ек : ТОгаегбабил еек 


{ 
риоБ11с уола баби1ЕОгаек (СатЕ саге) 


{ 


// Ничего не делать 
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Зарегистрируйте его в разделе <сазЕ1е> файла меь. сопЕ1 а: 


<саз1е> 
<сошропепе$5> 
<!-- Остальной код не изменяется - просто добавляется следующий новый узел --> 
<сотропепЕ 14="ОгдегбаЪЬт1 ЕЕег" 
зег\у1се="Рота1пМоде1 .Зегу1сез .ТОгаегби5иаЕфек, Бота1пМоде1" 
фуре="Рота1пМо4е] .бег\у1сез.РГаКеОгаегЗиьт1ЕЕег, БотазпМо4е1" /> 
</сопропепе5> 
</сазЕ1е> 


Теперь приложение можно запустить. 


Отображение сообщений об ошибках проверки достоверности 


Если вы зайдете на экран оформления заказа и введете неполные сведения о дос- 
тавке, приложение просто заново отобразит зтот зкран, не объясняя причин. Давайте 
заставим его отображать сообщения об ошибках, добавив Нет]. Уа11Ча1опбопиаку () 
в представление СВесКОое.азрх: 


<62>СЬеск об пом</62> 

Р1еазе епеег уоиг дефа115, ап ме'11 зЬ4р уоиг 90043 к1аВЕ амау! 
%$= Ныш1 .Уа11да1опбиттаку () %> 

... Остальное без изменений ... 


"Теперь если посетитель оформит заказ неправильно. то он получит итоговый спи- 
сок сообщений по результатам всех проверок достоверности, как показано на рис. 5.15. 
Если будет предпринята попытка отправить заказ при пустой корзине, в итоговом спи- 
ске сообщений появится фраза “Зогту, уоиг саг 1з етрёу!” (К. сожалению, ваша корзина 
пуста). 

Также обратите внимание, что текстовые поля, в которых обнаружен неверный ввод, 
будут выделены — это поможет пользователю быстрее найти причину возникшей про- 
блемы. Встроенные вспомогательные средства ввода АЗРМЕТ МУС выделяют себя авто- 
матически (назначая себе определенный класс С$5)}, когда обнаруживают зарегистри- 
рованное сообщение об ошибке, которое соответствует их собственному имени. 
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Рис. 5.15. Теперь сообщения об ошибках проверки достоверности 
отображаются на экране 
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Чтобы текстовые поля выделялись, как показано на рис. 5.15. в файл С$$ потребу- 
ется добавить следующие правила: 


.Е1е19-уа11Чае1оп-еггог { со1ог: гед; } 
„.1прие-уа119аЕ1оп-еггог { Богаег: 1рх 30119 гей; БаскКакоцпа-со1ог: #ЕЕееее; } 
.Уа11Ч9а1оп-зиитагу-еггогз { Еопе-мезаВе: Бо1а; со1ог: геад; } 


Отображение экрана с благодарностью за размещенный заказ 


В завершение процесса оформления заказа добавьте шаблон представления под 
названием Сотр1етеа. По соглашению он должен быть помещен в папку /У1емз/СагЕ 
проекта Мерот, потому что он будет визуализирован действием из СахЕСопего11ек. 
Щелкните правой кнопкой мапти на /У1емз /СагЕ и выберите в контекстном меню пункт 
АЧа-\Лем (Добавить=>Представление). В открывшемся окне введите имя представления 
Сотр1етеа, проверьте, что флажок СгеаЕ а энопау туред мем (Создать строго типизи- 
рованное представление) не отмечен (так как мы не собираемся визуализировать ка- 
кие-то данные модели) и щелкните на кнопке Ада (Добавить). 

Все, что понадобится добавить к шаблону представления — это небольшой фрагмент 
статической НТМГ-разметки: 


<азр:СопеепЕ СопкепЕР1асеНо1АегтрО="Т1Е1еСопфеепт®" гипаЕ="зегуег"> 
ЗрокЕз5фоге : Огаег библ Еееа 

</азр:СопеепЕ> 

<азр:Сопсепте СоптепЕР1асеНо1ЧегтТр="Ма1пСопеепе" гипас="зегуег"> 
<в2>ТВапКз! </62> 
ТрапКкз Еог р1ас1пта уоцг огдег. Ме'11 зЬ1р уопг доо@$ аз зооп аз розз1Ые. 

</азр:СопЕепЕ> 


Теперь можно проверить весь процесс выбора товаров и оформления заказа. После 
указания корректных сведений о доставке появятся страницы, показанные на рис. 5.16. 
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Рис. 5.16. Завершение оформления заказа 


Реализация класса Ета11Охдег$аЪт1 ег 


Осталось только заменить ЕакеогЧегбори1 ег (фиктивное средство отправки за- 
казов) реальной реализацией ТОгдег5ири1ЕЕег. Такая реализация могла бы сохранять 
заказ в базе данных, уведомлять администратора сайта с помощью 5М$-сообщений и 
запускать небольшой робот для отбора товаров на складе и подготовки их к отправке, но 
это задача не сегодняшнего дня. Пока ограничимся реализацией, которая будет просто 
отсылать детали заказа по электронной почте. Добавьте класс Епа11ОгдегзЗаютлЕфек в 
папку Зегу1сез проекта Рома1иМоде1: 
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роЬ11с с1азз Ема11Огаегби 61 Ефег : ТОгдегбарил еек 
{ 
сопзЕ зЕг1па Ма115аЪ]есЕ = "Мем огдег забил ефеа!"; 
зЕг1пд этЕрбегуек, па11Екощ, па11То; 
рир11с Ема11ОгаегЗиюта Е Еех (зЕу1па эпербегуег, зЕг1па ша1ЛЕкот, зЕг1п9 ма11То) 
{ 
// Получить параметры от контейнера ТоС 
$513.этЕрбегуег = зпёрбегуег; 
$61$.ща11Рхом = па11Егоп; 
$615 .ма11То = па11То; 
} 
риБ11с уо1а бири1еОгаег (СагЕ саг®) 
{ 
// Подготовить тело сообщения 
ЗЕг1п9Ви114ег Боду = пем 5Ег1пдВи119ег (); 
роду .Аррепа11ле ("А пех огаег Баз Бееп забила еЕеа"); // Отправлен новый заказ 
роду .Аррепа1 ле ("---"); 
роду .Аррепа| те ("ТЕепз:"); // Позиции заказа 
Хогеасй (уаг 11пе 1п саг®.Ь1пез) 
{ 

уаг зирсоса1 = 11пе.Ркодисе.Рг1се * 11пе.Оцапе1еу; 

Роду .-АррепаРогтаф ("{0} х {1} (зирбофа1: {2:с}", 11пе.Очапезеу, 
11пе.Ргоаисе.Мапе, 
зиБЕоса1); 

} 
роду .АррепаЕготща{ ("Тоса1 ог4ег уа1иае: {0:с}", 
саге .СотриеТоса1Уа1е ()); // Сумма заказа 
Боду .АррепаГ1пе ("---"); 
роду .Аррепа!Г1те ("$В1р $о:"); // Координаты для доставки 
роду .Аррепа|1пе (сак® .561рр1пареса11з.Мамте); 
роду .Аррепа[ те (саге .5Ь1рр1па0ета11$.11пе1); 
роду .Аррепа те (саге .551рр1п90еса11$з.11пе? ?? ""); 
роду .АррепаГ ше (саге. 561 рр1па0еса11з.11пеЗ3 ?? ""); 
роду .Аррепа[ пе (саге. 511рр1па9ефа11$з.С1еу); 
роду .Аррепа!|1те (саге. 561 рр1пареса11з.Зтаке ?? ""); 
роду .Арреп9 те (саге. 51 ррапарека11$.Соппеку); 
роду .Аррепа| те (саге .51рр1п90етха11$.71р); 


роау.Аррепа|1те ("---"); 
роду.АррепаГгогтах ("61 игар: {0}", // Нужна ли подарочная упаковка? 
саге. 311рр1п90ефа11$.С1ЕЕИгар ? "Уез" : "Мо"); 


// Отправить сообщение 
ЗшЕРС11ере зпЕрС11епе = пеи ЗшЕрСс11епт (эпЕрЗегуег); 
зпЕРС11еп®.3епа (пеи Ма11Меззаде (па11Екощ, та11То, Ма1 1506) есЕ, 
Боау.То3ЗЕг1па ())); 
} 
} 


Чтобы зарегистрировать это в контейнере 1оС, обновите в файле пе. сопЕЁ1ч узел, 
специфицирующий реализацию тОгдегЗи и {ег: 


<сопропепЕ 19="Огаегтби те кег" 
зегу1се="Боща1пМоЯе1 .Зегу1сез.тТОгдег$ иБи1ЕСех, БопалпМоае1" 
суре=" Роща1пМоде1 .бегу1сез.Ета11ОгдегбаБи1Е ет, ПБощазпМоае1"> 
<рагапефег$> 
<зтЕр5егуег>127.0.0.1</зтпЕр5егуег> <!-- Сервер указывается здесь --> 
<па11Ргоп>5рогеззкогевехаир]1е .соп</па11Екот> 
<та11То>аЯт1п@ехатр1е .сом</ща11То> 
</рагащесегз> 
</сотшропеп{е> 
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Упражнение: обработка кредитных карт 


Если вы почувствовали уверенность в своих силах, попробуйте следующее. Большинство сайтов 
электронной коммерции выполняют обработку платежей кредитными картами, но почти все реа- 
лизуют зто по-разному. АР!-интерфейсы варьируются в соответствии с платежной системой, на 
которую вы подписаны. Таким образом, имея следующую абстрактную службу: 


риБ11с 1п6егЕасе ТСгеЯд1ЕСагаРгосеззог 
{ 

Тгапзасе1опВези1Е ТакеРаумепе (СтеЯ1ЕСагЯ саг, Яаес1ща1 атопп®); 
} 


роБ11с с1азз Схеа1ЕСага 

{ 
руЮ11с зЕх1па СагЯМипфег { деф; зес; } 
ру611с зЕг1па Сагабо1АегМате { деё; зе®; } 
руБ11с $Ег1па Ехр1куПВаее { дее; зеё; } 
руЮ11с зЕг1па бесих1®уСо4е { дее; зе{; } 

} 


риЮ11с епим ТкапзасЕ1опВези1е 


{ 


Зиссезз, СагЯМапегТпуа11Я, СагаЕхругеЯ, Ткапзас®1опрес11теа 
} 


сможете ли вы расширить СаскЕСопЕго11ег для работы с ней? Это потребует выполнения пе- 
речисленных ниже шагов. 


® Обновление конструктора СагЕСопеко1 Тег для получения зкземпляра ТСтеЯ1ЕСагаРгосеззок. 


® Обновление /У1еиз/СагЕ/СВескОчь .азрх для запроса у покупателя подробной инфор- 
мации о кредитной карте. 


® Обновление метода действия СпесКОчеЕ контроллера СахЕСопЕго11ек, обрабатываю- 
щего запросы РОЗТ, для отправки детальной информации о кредитной карте зкземпляру 
ТСхе91ЕСагаРгосеззок. Если транзакция завершается неудачно, потребуется отобразить 
соответствующее сообщение и не отправлять заказ ТОкаех би бют ег. 


Это демонстрирует сильные стороны компонентно-ориентированной архитектуры и 10С. Появля- 
ется возможность проектировать, реализовывать и проверять поведение обработки кредитных 
карт Са Сопего11ег с помощью модульных тестов, не открывая веб-браузеров и не строя 
конкретную реализацию службы ТСге91ЕСагаРгосеззохг (а просто используя ее фиктивный 
экземпляр). Для запуска его в браузере можно реализовать какой-то вариант фиктивной служ- 
бы гаКеСгхеЯ91ЕСагаРгосеззох и присоединить его к контейнеру 10С в файле иеб.соп#1(. 
При желании можно построить несколько реализаций, служащих оболочками для реальных АР!- 
интерфейсов обработки кредитных карт, и переключаться между ними простым редактированием 
файла ме . сопЕ1 9. 


Резюме 


На этом та часть приложения Зро юге, которая обращена к внешнему миру, прак- 
тически завершена. Возможно, предложенное решение не претендует на то, чтобы со- 
ставить конкуренцию порталу электронной торговли Атагоп, но все же реализованы 
просматриваемый по страницам и по категориям каталог товаров, аккуратная малень- 
кая корзина для покупок и простой процесс регистрации заказов. 
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Архитектура с четко разделенной ответственностью означает возможность просто- 
го изменения поведения любой части приложения (например, оформления заказа или 
определения корректного адреса доставки) в одном очевидном месте, не беспокоясь о 
несогласованности и нежелательных последствиях. Можно легко изменять схему базы 
данных, не затрагивая остальной части приложения (лишь меняя отображения ЫМО ю 
591). Приложение довольно хорошо покрыто модульными тестами, что позволяет во- 
время заметить, если какое-то поведение непреднамеренно будет нарушено. 

В следующей главе предстоит заверитить работу над приложением, добавив средства 
управления каталогом (те. СКО} для администраторов, в том числе возможности об- 
новления, сохранения и вывода изображений товаров. 


ГЛАВА 6 


Приложение 
эрог5боге: 
администрирование 
и финальные 
усовершенствования 


настоящему моменту большая часть приложения Эро юге готова. Подведем 
краткие итоги. 


® Вглаве 4 была создана простая модель предметной области, включая класс Ркодис® 
с его основанным на базе данных репозиторием, а также установлены другие цен- 
тральные части инфраструктуры, такие как контейнер оС. 


® В главе 5 были реализованы элементы классического пользовательского интер- 
фейса приложения электронного магазина: навигация, корзина для покупок и 
процесс оформления заказа. 


В этой завершающей главе, посвященной приложению Зрог юге, основная задача 
связана с обеспечением администратора сайта инструментами обновления каталога то- 
варов. Здесь будут рассмотрены следующий вопросы. 


® Предоставление пользователям воэможности редактировать коллекции элементов 
(создание, чтение. обновление и удаление элементов модели предметной области) 
с проверкой правильности каждой операции. 


® Использование аутентификации с помощью форм (Еогт Аи епйсавоп) и фильт- 
ров для защиты контроллеров и методов действий с представлением при необхо- 
димости соответствующих приглашений на вход. 


® Получение загружаемых файлов. 


® Вывод изображений, хранимых в базе данных ЗОГ. 
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Ымж®зннЪБ ид 


Тестирование 


До настоящего момента вы уже видели большой объем тестового кода и должны иметь представле- 
ние о том, как применять методы разработки, управляемой тестами (ТОО), при создании приложе- 
ний АЗРМЕТ М\УС. Тестирование продолжается и в зтой главе, но теперь оно будет более кратким. 
В тех случаях, когда код тестов либо очевиден, либо слишком многословен, полные листинги при- 


водиться не будут, а только несколько ключевых строк. Полные коды всех тестов входят в состав 
материалов, доступных для загрузки на веб-сайте издательства. 


Добавление средств управления каталогом 


В соответствие с общепринятыми соглашениями относительно управления коллек- 
циями элементов, пользователям должны быть предоставлены два типа экранов: список и 
редактор (рис. 6.1). Вместе они позволяют пользователю создавать, читать. обновлять и 
удалять элементы коллекции. (Эти средства известны под общей аббревиатурой СКОО.) 


НЕ осгееп ЕЧИ Нет: ВазкефаН 

Нет АСНоп$ Мате: Вазкетай 

_ Вазкейван ЕС |! Оеее Безсирноп: = Воипб апё огапое 
Змитиииа зВои$ БАН | беще Саебогу: Вай датез 
‚Вип $Ноез ЕЧН | еее Рисе ($): 25.00 


Заме свапаез Сапсе! 


АВА пем ет 


Рис. 6.1. Эскиз пользовательского интерфейса СВИР для каталога товаров 


СКИУР — одно иэ тех средств, которые довольно часто приходится реализовывать 
веб-разработчикам. На самом деле настолько часто, что среда \1зиа! Зыло1о старает- 
ся помочь в этом, предоставляя возможность автоматической генерации связанных с 
СКОРО контроллеров и шаблонов представлений для специальных объектов модели. 


На заметку! В этой главе встроенные шаблоны \Мзиа! Это будут использоваться лишь иногда. 
В большинстве случаев мы будем редактировать, сокращать, а то и вообще полностью заме- 
нять автоматически сгенерированный код СВУО, делая его более сжатым и лучше подходя- 
щим для решения конкретной задачи. В конце концов, приложение Зрой$ юге претендует быть 
вполне реалистичным приложением, а не демонстрационным, специально созданным для того, 
чтобы продемонстрировать АЗР.МЕТ МУС с лучшей стороны. 


Создание класса Аат1пСопЕго11ех — 
места для размещения средств СВИО 


Давайте реализуем простой пользовательский интерфейс СКОРО для каталога товаров 
ЗрогЁз5юге. Вместо перегруженного РтодисЕ зСопего11ех создадим новый класс контрол- 
лера по имени Аат1пСопего11ег (щелкнув правой кнопкой мыши на папке /СопЕтго11егз 
и выбрав в контекстном меню пункт Ад=>СопгоНег (Добавить Контроллер). 
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На заметку! Решение создать новый контроллер вместо расширения РеодасЕзСоврего11ек 
продиктовано сугубо личными предпочтениями. На самом деле нет никакого ограничения на 
количество методов действий, которые можно включать в один контроллер. Как и в объектно- 
ориентированном программировании, вы вольны организовывать методы и их ответственность 
по своему усмотрению. Разумеется, вещи следует сохранять в хорошо организованном поряд- 
ке, поэтому помните о принципе одиночной ответственности и выделяйте новый контроллер 
при переключении на другой сегмент приложения. 


Если вам интересно посмотреть на код СКОО, сгенерированный \1з0а| Зло, перед 
щелчком на кнопке Ада (Добавить) отметьте флажок АО асйоп пейод$ юг Сгезе, Ирдае 
апа Беае эсепано$ (Добавить методы действий для сценариев создания, обновления и 
удаления). Это приведет к генерации класса, который выглядит так, как показано ниже": 


руБ11с с1азз АатаипСопЕко11ег : Сорёго11ег 
{ 
риБ11с АсЕ1опВез1е ГТпдех{) { кебакп \1ем(); } 
руЮю11с АсЕ1опВези1Е Беба113 (1пе 1а) { кебиагп У1еи(); } 
рир11с АсЁ1опВез1:1Е Сгеафе() { гебигп Узеи(); } 
[Ассере\егЬз (НЕЕрУегЬз .Роз{) ] 
рую11с АСЕ1опВези1е Сгеаке (ЕогиСо11есЕ1оп со11есЕ1оп} 
{ 
Ску { 
// ТОРО: добавить сюда логику вставки 
хееотр Вед1гесЕТоАсетоп ("тпаех"); 
} 
саесь { 
тебагп У\У1ем(); 


} 

риБ11с АсЕ1опВези1Е ЕЯ1е (1пе 1а) { гебагп Узем(); } 
[АссереУетьз (НЕбрУетЬз .Роз{) ] 

руЬ11с АсЕ1опВезо1Е Е@1е (1пЕ 1а, РогиСо11есЕ1оп со11есЕ1оп) 


{ 
Ску 1 
// ТОРО: добавить сюда логику обновления 
гебигп ВКед1гесеТоАсЕ1 оп ("Тпаех"); 


} 
саесь { 
гебакп Улем(); 


} 


Автоматически сгенерированный код не совсем подходит для приложения Эро юге. 
Ниже перечислены причины. 


® Пока еще не очевидно, нужны ли все эти методы. Действительно ли понадобится 
действие Оега113? Наличие заглушек для всех методов действий в автоматиче- 
ски сгенерированном коде является вполне разумным, однако это противоречит 
принцинам ТОО. При разработке, управляемой тестами. полагается, что методы 
действий не должны даже существовать до тех пор, пока с помощью тестов не 
будет установлено, что они действительно нужны, и должны вести себя каким-то 
определенным образом. 


х С целью экономии пространства некоторые комментарии и переносы строк удалены. 
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® Мы можем написать более ясный код. чем сгенерированный автоматически, ис- 
пользуя привязку модели для получения отредактированных экземпляров Реодисе 
в качестве параметров методов действия. Кроме того, мы определенно не хотим 
перехватывать и поглощать все возможные исключения, как это делает Еазе() по 
умолчанию, поскольку это приведет к утере и игнорированию важной информа- 
ции, такой как ошибки, сгенерированные базой данных при попытке сохранения 
в ней записи. 


Речь вовсе не идет о том. что использование кода, генерируемого \1зиа] Знаю, — 
всегда плохо. Фактически всю систему генерации кода контроллеров и представлений 
можно построить с помощью одного лишь мощного механизма шаблонов Т4. Это по- 
зволяет создавать и распространять шаблоны кода, которые идеально подходят для 
удовлетворения существующих соглашений и принципов проектирования приложений. 
Вдобавок это может быть замечательным путем для быстрого вовлечения новых разра- 
ботчиков в принятый у вас процесс кодирования. Однако пока что мы будем писать код 
вручную, потому что это не трудно, а также потому, что это даст вам лучшее понимание 
работы АЗРМЕТ МУС. 

Итак, удалите все автоматически сгенерированные методы действий из Адп1исопего11ег 
и затем добавьте зависимость оС для репозитория товаров, как показано ниже: 

руб11с с1азз Ади1иСопего11ег : Сопего11ег 

{ 

ре1хафе ТРкоаасЕ5Вероз1еокгу ргодис+=Вероз1+оку; 
РУБ11с Аап1пСопего11ек (ТРкодисе=Вероз1огу реодисеКероз1+оку) 
{ 

{515 .реоФасЕзВероз1+оху = ркодисеКероз1®оку; 


} 


Для поддержки экрана списка (рис. 6.1) понадобится добавить метод действия, кото- 
рый отобразит все товары. Следуя соглашениям АЗРМЕТ МУС, назовем его тпаех. 


Тестирование: действие тпаех 


Действие Тпаех контроллера Адт1псопЕто11ек может быть довольно простым. Все, что оно 
должно делать — это визуализировать представление, передавая ему все товары из репозито- 
рия. Выразите это требование, добавив в проект Тезез новый класс [ТезеР1хЕаке] по имени 
Ат псорего11етТезе 5: 


[ТезеЕ1хЕоге] 
руЮ11с с1азз Ади1пСопего11егТезез 
{ 
// Используем этот репозиторий везде в Ади1 пСопего11егТезез 
рк1уафе Моч.Моск<ТРЕкодисе5Вероз1еогу> тосквероз; 
// Этот метод будет вызываться перед прогоном каждого теста 
[Зее ор] 
руБ11с уо1а ЗефОр () 
{ 
// Создать новый макет репозитория на 50 товаров 
115&<РгодисЕ> а11Ргодисез = пем Ъ1зЕ<РкоансЕ> (); 
Фок (Е 1 = 1; 1 <= 50; 1++) 
а11РгодисЕз .Ааа(пем РгодисЕ (РгоднсеЕТр = 1, Маше = "Ргодасе " + 4} 
поскВероз = пем Моа.Моск<ТРкодисе$Вероз16оку> (); 
поскКероз .бееир (х => х.Ргодиасез) 
.Весигпз (а11РгодисЕз.АзОпегуаю1е()); 
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[ТезЕ] 
руЮ11с уо1а Тпаех АсЕ1ой 1133 А11 Ркодисе$ () 
{ 


// Подготовка 
Аа пСопего11ех сопёго11ех = пем Ади1иСопЕго11ех (посКкВероз.ОБ]десЕ); 


// Действие 
\У1еиВези1Е гези1Ез = сопего11ег.Траех (); 


// Утверждение: визуализировать представление по умолчанию 
Аззеге .Т5Етреу (гези1Е5.УзеиМамте) ; 


// Утверждение: проверить, что включены все товары 
уаг ргоазКепдегеа = (11зЕ<РгоЧасЕ>) гез 13 .УМлем ака .Мо@е1; 
Аззеге.АгеЕаца1 (50, рхоазВепаегеа.Сопп®); 
Бог (1 =0; 1 < 50; 1++) 
Аззеге.АгеЕаиа1 ("Рго@исе " + (1+1), ркоа$Вепаегея[1] .Мапе); 


} 


На этот раз мы создаем единственный фиктивный репозиторий товаров (тоскКВероз, с0- 
держащий 50 наименований товаров) для многократного использования во всех тестах 
Ада псопего11егТезез (в отличие от СагЕСопего11ехТезез, где для каждого теста конструи- 
руется отдельный фиктивный репозиторий). Здесь также отсутствует понятие “правильного” или 
“неправильного” подхода, а просто демонстрируются различные варианты, чтобы вы могли вы- 
брать из них тот, который больше подходит в конкретной ситуации. 


Этот тест определяет потребность в методе действия Тпадех () класса Адт1 псопего11ег. 


Другими словами, отсутствие упомянутого метода приведет к ошибке компиляции. 
Давайте добавим этот метод. 


Визуализация списка товаров из репозитория 


Добавьте в контроллер Адт1пСопЕго11ех метод действия по имени Тпдех: 


руб11с У1емВези1е Тпаех() 
{ 

тебихгп У1ем (ргодисЕКероз1®оку. Рго@исез .То11 3 ()); 
} 


Такого простого кода вполне достаточно, чтобы тест Тпдех_АсЕ1ой_115Е3_А11_ 
2кодисез() прошел успешно. Теперь понадобится только создать подходящий шаблон 
представления, который визуализирует список этих товаров, и экран списка СКВОШ бу- 
дет готов. 


Реализация шаблона представления списка товаров 


Прежде чем добавить новый шаблон представления для этого действия, давайте соз- 
дадим новую мастер-страницу для всего административного раздела. В окне ЗошНоп 
Ехрогег щелкните правой кнопкой мыши на папке /У1еиз/5вакед и выберите в контек- 
стном меню пункт АЧЧ=>Мем Мет (Добавить=>Новый элемент). В открывшемся всплы- 
вающем окне выберите шаблон М\УС \Леми Мачег Раде (Мастер-страница представления 
МУС) и назовите его Адт1 и .Мазеег. Поместите в него следующую разметку: 


<%@ Мазеег Гапдиаде="С#" Трвег1Ез="Зузеем. Мер .Мус.\У1емМазеегРаде" %> 
<!РОСТУРЕ БЕмт РОВЬТС "-//МЗС//ОТЬ ХНТМЬ 1.0 Тгапйз1Е1опа1//ЕМ" 

"ВЕЕр://мим.и3 .ога/ТВ/хЬ 11 /ОТО/хЬ 11-Е хапз1Е1опа1.а6&"> 
<В 01 хи]тз="ВЕЕр://мим.м3 .0ог9/1999/хЬЕт" > 
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<ВеаЯ гипас="зегует"> 
<11пК ге1="5у1езреее" ЬхеЕ="- /Сопеепе/аЯт1тз5у1е5.сзз" /> 
<Е11е><азр:СопеепЕР1асеНо1Чег ТО="Т11еСопеепе" гипаф="зегуег" /></Е1Е1е> 

</Веаа> 

<Боау> 
<азр:СопеепЕР1асеНо1Чег Тр="Ма1пСопеепЕе" гипае="зегуех" /> 

</Боау> 

</Вет1> 


Эта мастер-страница ссылается на файл С5$5, поэтому создайте такой файл по име- 
ни адт1пз$у1ез.сз$ в папке /Сопеепе со следующим содержимым: 


ВОрУ, ТО { ЕопЕ-Еат11у: бедое ОТ, Уегдапа } 
Н1 { раая1т9: „.5ет; рааа1па-Еор: 0; ЕопЕ-мелаье: 6019; 
ЕопЕ-312е: 1.5ещ; рохаег-Боефош: 2рх з0114 дтау; } 
ОТУфсопеепЕ { рааа1та: „.9ещ; } 
ТАВТЕ.Сг1А ТО, ТАВГЕ.Сг1а ТН { Бохдег-БоЕеот: 1рх ЧосфеЯ дгау; кехЕ-а11апт:1еЕе; } 
ТАВТГЕ.Сг1а { Богаег-со11арзе: со11арзе; и1аев:100$; } 
ТАВЬЕ.Сг1а ТН.Мищехг1сСо1, ТаБ1е.Сг1а То.Мищег1сСот1 { 
ТехЕ-а119п: г19ЪЕ; раЯ@а1па-к1аве: 1епщ; } 
ОТУ.Меззаде { раскагоцпЯ: дгау; со1ог:И1Ее; радЯ1та: .2ещ; шакалп-бор:.25ещ; } 
.Е1е19-уа11аЕ1оп-етггог { со1ог: геа; } 
„1прие-Уа11ЧаЕ1оп-еггог { Богаег: 1рх 30114 ге; расКогоипа-со1ог: #ЕЕееее; } 
.Уа11ЧаЕ1отп-зоитагу-еггогз { ГопЕ-мезаре: Бо1а; со1ог: геа; } 


После создания мастер-страницы можно добавить шаблон для действия тпдех кон- 
троллера Ааи1псопего11ет. Щелкните правой кнопкой мыши внутри метода действия и 
выберите в контекстном меню пункт Ада Мем (Добавить представление). В открывшемся 
окне конфигурируйте новый шаблон представления, как показано на рис. 6.2. Обратите 
внимание, что в качестве мастер-страницы выбрано Ади1п .Мазкег (а не 514е.Мазкек, 
как обычно). Также в этом случае мы предлагаем \1зиа! З6а@ю предварительно запол- 
нить новое представление разметкой для визуализации списка экземпляров Ргодисе. 


На заметку! Когда в списке \Лем/у сотепЕ (Содержимое представления) выбран вариант М5 
(Список), среда \Мзиа! Зи неявно предполагает, что классом данных представления должен быть 
ТЕпимегаю1е<вашКласс>. Это значит, что набирать ТЕпимега61е<...> вручную не придется. 
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Рис. 6.2. Установки для представления Тпдех 
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После щелчка на кнопке Ада (Добавить) \15ца1 Зе ю просматривает определение 
класса Ргодис® и затем генерирует разметку для визуализации списка экземпляров 
РкоаисЕ в виде таблицы с отдельным столбцом для каждого свойства класса. Разметка 
по умолчанию несколько многословна и нуждается в настройке, чтобы соответствовать 
существующим правилам С$$. Отредактируйте ее следующим образом: 


<%@ Раде Т1Е1е="" Тападиасе="С#" МазфегРадеЕ11е="- /У1емз/ЗВагеЯ/Ааилр.Мазфег" 
ТпБег1{5="бузрем. Иер .Мус.\У1емРаде<ТЕпимега1е<Пота1пМоде1 .ЕпЕ11ез.Ргодись>>" %> 
<азр:СопеепЕ СопепЕРТасеНо1аехтр="Т1Е1еСопеете" гипае="зегуек"> 
АЧп1п : АТ Рхгодис®е$ 
</азр:СопЕепе> 
<азр:СопеепЕ СопепЕР1асеНо14ехтТр="Ма1пСопфеепе" гопа*="зегуег"> 
<61>А11 ргодисЕ$</61> 
<Еаю1е с1азз="Су19"> 
<Ех> 
<ЕБ>ТО</Ев> 
<ЕБ>Мапе</Ев> 
<ЕБ с1азз="Минег1сСо1">Ре1се</ ЕВ» 
<ЕВ>АсЕ10п8</ЕБ> 
</Ех> 
<%$ Еогеась (уатг 1®ем 1п Мо@ет) { %> 
<Етг> 
<Е9><$%= 16ещ.РкодасЕетр %></Е9> 
<Е9><%= 1ет.Маше %></%а> 
<ЕЯ с1азз="Минег1сСо1"><%= 16ем.Рхг1се.Тобег1па ("с") %></Еа> 
<Еа> 
<%= НЕмТ.Асетопр1пК ("Еа1е", "ЕЗЛе", пем {15ещ.Ргодасетро}) %> 
<%= НЕш1.АСЕтопТлюК ("Ре1ефе", "Бе1ефе", пем {1+ем.Рходосето}) %> 
</Еа> 
</Ег> 
<% } %> 
</тар1е> 
<р><5= НЕи1.АСЕТопЬ1 ИК ("АДЯ а пем ргодасе", "Стеасе") $></р> 
</азр:Сопеепф> 


На заметку! Этот шаблон представления не осуществляет НТМЕ-кодирование детальной инфор- 
мации о товарах в процессе генерации разметки. Это нормально, если редактировать эту ин- 
формацию разрешено только администраторам. Однако если отправка или редактирование 
информации о товарах доступна неизвестным посетителям, очень важно использовать вспо- 


могательный метод НЕм1.Епсоде () для блокирования атак Х$$. Более подробные сведения 
0б зтом ищите в главе 13. 


Чтобы проверить, все ли работает, запустите приложение в режиме отладки (нажав 
<Р5>) и введите в адресной строке браузера нЕЕр: / /1оса1Ъоз® : порт/Адпап/Тпаех, как 
показано на рис. 6.3. 

Итак, экран со списком готов. Однако его ссылки на редактирование/удаление/до- 
бавление пока не работают, потому что они указывают на методы действий, которые 
еще не созданы. Давайте создадим их. 


Построение редактора товара 


Для того чтобы предоставить средства создания и обновления, добавим экран ре- 
дактирования товара, подобный показанному в правой части рис. 6.1. Эта задача раз- 
деляется на две части: во-первых, отображение экрана редактирования и, во-вторых, 
обработка отправки введенных пользователем данных. 
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Рис. 6.3. Экран со списков товаров, предназначенный для администратора 


Как и в предыдущих примерах, мы создадим один метод, реагирующий на запросы 
СЕТ и визуализирующий начальную форму, и второй метод, реагирующий на запросы 
РОЗТ и обрабатывающий отправки формы. Второй метод должен записывать входные 
данные в репозиторий и перенаправлять пользователя обратно на действие тпаех. 


Тестирование: действие аз 


Если вы следуете методике ТОО, то наступил момент добавления теста для перегрузки действия 
ат, реагирующей на СЕТ-запросы. Потребуется проверить, что, например, Еаз + (17) визуа- 
лизирует представление по умолчанию, передавая Ртодисе 17 из фиктивного репозитория в 
качестве объекта модели, подлежащего отображению. Фаза утверждения теста должна включать 
приблизительно такой код: 


РгоаисЕ гепаегеаРгодисЕ = (Рходос®) гези1е .Утемраба .Моде1; 
Аззеге.АгеЕачиа1 (17, гепаегедРгодасе .Ргодасетр) ; 
Аззеге.АгеЕаца1 ("РгоаосЕ 17", гепдегеаРгодас+.Мапе); 


Из-за попытки обращения к пока еще несуществующему методу Баз () класса Ааа пСопего11ег 
этот тест приведет к ошибке компиляции, тем самым выдвигая требование создать этот метод 
Еа1 4 (). При желании можно сначала создать заглушку метода ка1+ (), которая просто приве- 
дет к генерации исключения МоЕТир1етепеедЕхсерЕ1от — зто удовлетворит компилятор и 
1РЕ-среду, оставив полосу красного цвета в графической среде МИпИ (что будет напоминать о 
необходимости соответствующей реализации метода ка1* () ). Создавать или нет такую заглуш- 
ку метода — вопрос персональных предпочтений. Обычно ее создают те, кого раздражают частые 
ошибки компиляции. 


Полный код этого теста входит в состав материалов, доступных для загрузки на веб-сайте изда- 
тельства. 
Е ЕЕ АЕ ЕЕРЕЕЕЕЕЕЕЕЕИИЕЕЕ 


Все. что должен делать Е91* () — это извлечь запрошенный товар и передать его в 
виде Мо4е1 некоторому представлению. Ниже приведен код, который понадобится до- 
бавить в класс Адт1 псорего11 ег: 


[АссереУекьз (НЕфрУетьз .Сеф) ] 
ру611с У1емВези1е Еа1Е (1пЕ ргодисета) 
{ 
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РгоЧисЕ ргодисЕ = (ЁЕгом р 1п ргоаисЕзВероз1Еогу.Ргодисез 
уреге р.РгодосЕТр == ргодисета 
зе1есЕ р) .Е1гзЕ(); 

тееигп У1еи (ргодисЕ) ; 


} 
Создание пользовательского интерфейса редактора товаров 


Конечно, для этого понадобится добавить представление. Добавьте новый шаблон 
представления для действия Е91+, указав Адп1 п .Мазтег в качестве его мастер-страни- 
цы и сделав его строго типизированным для класса Ргодиск. 

При желании в списке \Уе\ми сощег можно выбрать вариант ЕЯЙ (Редактор)}, что за- 
ставит \ 15а! За сгенерировать базовое представление для редактирования Ргодиск. 
Однако полученная в результате разметка снова получается несколько многословной, и 
большая ее часть просто не нужна. Либо установите \Мем/ сощег{ в Етрйу (Пусто), либо 
отредактируйте сгенерированную разметку, приведя ее к следующему виду: 

<%@ Раде Т1{1е="" Тапдтаде="С#" МазфегРадеЕ11е="- /У1леиз/5ВагеЯ/Аатаи.Мазеег" 

Торег1з="бузбем. Мер .Мус .УземРаде<ВБота1пМо4е1 .ЕпЕ1е1ез.Рго@ис®>" $%> 
<азр:СопЕепе СопеепЕР1асеНо1аег1р="Т1Е1еСопёепе" гираЕ="зегуег"> 
Адт1п : Еа1Е <%= Моде1.Мапе %> 

</азр:СопеерЕ> 

<азр:СопЕепЕ СопЕепЕРТасеНо1Аег10="Ма1пСопЕ еп" гипаё="зегуег"> 

<в1>Е91Е <%= Моде1.Маше $></61> 


<% и51па (НЕшТ.Веад1пЕоги ())} {%> 
<%= НЕш1.Н1ааеп ("РгодисЕТЬ") %> 
<р> 


Маше: <%= НЕт1.ТехЕВох ("Мапе") $> 
<491у><%= Нет1 .Уа11даЕ1опМеззаде ("Мате") %></91у> 
</р> 
<р> 
Резсг1ре1оп: <%= НЕ .ТехеАгеа ("Резст1ре1оп", по11, 4, 20, па11) %> 
<а1\%><%= Н1 .Уа11АаЕ1опМеззаде ("Резсг1рЕ1оп") %></а1у> 
</р> 
<р> 
Рг1се: <%= НЕеш1.ТехЕВох ("Рг1се") %> 
<а1у><%= НЕм1.\Уа11аа®1опМеззаде ("Рг1се") %></а1у> 
</р> 
<р> 
Сафедогу: <%= НЕш1.ТехеВох ("Сафедогу") %> 
<а1\у><%= НЕи1 .Уа11Аа*1опМеззаде ("Сафедогу") %></91\> 
</р> 
<1приЁ Еуре="зири1 Е" уа1ие="бауе" /> &пюзр; &пюзр; 
<%$=Нет1.АсетоптТ1пК ("Сапсе1 апа кебогп ®о Т15е", "Тпдех") %> 
<$ } %> 
</азр:СопеепЕ> 


Это не самый изящный дизайн из когда-либо созданных, но над графическим оформ- 
лением можно будет поработать позже. Чтобы добраться до этой страницы, необходимо 
перейти на экран /Адт1о/тпаех (АП Ргодис{$ (Все товары)) и щелкнуть на любой из ссы- 
лок редактирования (ЕЯЙ). Откроется только что созданный редактор товара (рис. 6.4). 


Обработка данных, отправляемых редактором 


Если вы отправите эту форму. то получите ошибку 404. Мо! Еоипа (не найдено), пото- 
му что метод действия под названием Еа1+ (), который должен реагировать на запросы 
РОЗТ, пока не существует. Следующей задачей будет его добавление. 
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Рис. 6.4. Редактор товара 


Тестирование: отправка данных из редактора 


Перед реализацией перегрузки метода действия кат (), реагирующей на запросы РОЗТ, до- 
бавьте в Адт41пСопЕго11егТезЕз новый тест, который определит и проверит поведение нового 
действия. Необходимо проверить, что при получении экземпляра Реодис+ метод сохранит его в 
репозитории, вызвав ргодисЕВероз1фогу. ЗауеРгодисе () (пока не существующий метод). 
Затем посетитель должен быть перенаправлен обратно к действию тпаех. 
Ниже приведен код теста: 
[ТезЕ] 
рур11с уо1а Еа1Е АсЕ1оп_бауез_РгобисЕ То Вероз1®огу Апа Ве91гесез То_Тпаех () 
{ 

// Подготовка 

Аат1пСопего11ег сопЕго11ег = пеи АдиапСорего11етг (поскВероз$ .ОБ]есЕ); 

РгоаисЕ пеиРгодисЕе = пеи Ргодосе (); 

// Действие 

уаг гезо1Е = (Вед1гесЕеТовои в евези1&) сопЕго11ег.Еа1+ (пемРго@осе); 


// Утверждение: товар сохранен в репозитории и произошло перенаправление к Тпаех 
поскВероз .Уетг1Еу (х => х.бауеРгодосе (пемРгодос®) ); 
Аззеге.АгеЕаоа1 ("Тпаех", гези1е.ВопееУа1Тоез [“асЕ1оп"]); 


} 


Этот тест вызовет сразу несколько ошибок компиляции: пока еще нет перегрузки Еаз + (), при- 
нимающей экземпляр Реодасе в качестве параметра, и ТРеодисЕзВероз1огу не определяет 
метода ЗауеРгодисе (). Сейчас мы восполним эти недостатки. 


Можно также добавить тест, определяющий поведение при недействительных входных данных — 
метод действия должен заново отобразить представление по умолчанию. Для змуляции недей- 
ствительных данных добавьте в фазу подготовки теста следующую строку: 


сопЕго11ег.Моае1 5$ аее .АадЯМоде1Етгохг ("бомеРгорегеу", "Со 1пуа11@Я дафа"); 


Далеко продвинуться в сохранении обновленного Ргодис* в репозитории не удаст- 
ся, пока интерфейс ТРгодасЕВероз1еогу не предоставит некоторый метод сохранения 
(и если вы придерживаетесь методики ТОО, то последний тест вызовет ошибку компи- 
ляции, связанную с применением метода бауеРго@исе ()). 
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Обновите определение Тргодис&Веро$1огу: 


рую11с 1пегЕасе ТРгодосеВероз1®огу 


{ 
1Очегуаю1е<Ргодисо> Ргодас®е$ { дее; } 
\%014 бауерРгодис® (РгодасЕ ркодис®); 


} 


Теперь вы получите еще больше оптибок компилятора, потому что ни одна из кон- 
кретных реализаций — ни гаке?РгодисеВероз1кохгу, ни $а1РгодисЕВероз1+оку — не 
включает в себя метода ЗауеРго@исе (). 

Чтобы избежать ошибок, в Гаке?РгоЧисеВероз1еогу можно добавить заглуш- 
ку, которая вызовет генерацию исключения МоеТир1етепееЯЕхсере1оп, но для 
5а1РгодисЕКероз1+огу понадобится действительная реализация: 


рию11с уо1А бауеРго@асе (Рго@исЕ ргодос®) 
{ 
// Если это новый товар, просто присоединить его к ВафаСопеехЕ 
1Е (ргодасе.Ргодасетр == 0) 
ргодисЕзТаЮю1е.ТпзегЕОпбоармт (ргодис®); 
е1зе { 
// Если обновляется существующий товар, поручить 
// рабаСопЕехЕ сохранение этого экземпляра 
ргодисЕзТа1е.АеЕасв (рго@ос®) ; 


// Также поручить БабаСопеехЕ обнаружение изменений, 
// произошедших с момента последнего сохранения 
ргодисезТаЬ1е .Сопеехе .ВеЕгезв (ВеЕгезВМоде .КеерСоггепЕУа1аез, рго@ис®); 


} 
ргоаосЕзТаю1е.СопеехЕ . Зиби1ЕСрапаез (); 


} 


Теперь вы готовы реализовать перегрузку метода действия Еа1+ (), реагирующую 
на запросы РОЗТ, в классе Ади1рСорЕго11ег. Шаблон представления в /\У1еиз /Ади1о/ 
ЕЧ1Е .азрх имеет элементы управления вводом с именами, соответствующими свойст- 
вам РгодисЕ, поэтому, когда форма передает данные методу действия, можно восполь- 
зоваться привязкой модели для получения экземпляра РгодисЕ как параметра метода 
действия. Все что понадобится сделать — это сохранить его в репозитории: 


[АссерЕУегьз (НЕЕрУетЬз .Роз®) ] 
рир11с АсЕ1опВези1е Еа1+ (РгодисЕ рго@осе) 
{ 
ЛЕ (Моаде15аке.т1зУа11а) { 
ргодосЕВероз1Еогу .бауеРгодос® (ргодис®) ; 
Тепррака ["пеззаде"] = рго@исе.Матше + " Ваз Юееп зауеа."; 
тебогтп Кеа1тесЕеТоАсетог ("Тпдех"); 
} 
е1зе // Возникла ошибка проверки достоверности; 
// отобразить заново то же представлени 
тееиги Улеи (ргоаис®); 


} 


Отображение подтверждающего сообщения 


Обратите внимание, что после сохранения данных это действие добавляет сообще- 
ние с подтверждением в коллекцию ТепрПрака. Но что собой представляет Тепррата? Это 
новая концепция АЗРМЕТ МУС (в традипионном \еБКогил$ нет аналога Тепррафа, хотя 
есть на других платформах веб-разработки). Тетрраеа подобна коллекции 5езз1оп, но с 
тем отличием, что ее значения сохраняются только в течение одного НТТР-запроса, по- 
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сле чего отбрасываются. Подобным образом Тепррата автоматически очищается, упро- 
щая сохранение данных (например, сообщений о состоянии) между перенаправлениями 


НТТР но не дольше. 


Поскольку значение Тепррата ["пеззаде"] будет храниться строго для одного сле- 
дующего запроса, его можно отобразить после перенаправления НЛТР 302, добавив в 


шаблон мастер-страницы /\1еиз/5рагед/Ади1п .Мазеег следующий код: 


<Боау> 
<% 1 (Тепррафа ["меззаде"] != по11) { $> 


<91у с1а55="Меззаде"><%= НЕ] .Епсоае (Тепрраха [ "пеззаде"]) $></а1у> 


<$ } %> 


<азр:СопрепЕР1асеНо14ег Тр="Ма1пСопЕепе" гипаё="зегуег" /> 
</Боау> 


Опробуйте модифицированный редактор товара в браузере. Теперь можно обновлять 


записи РгодисЕ, получая каждый раз подтверждающее сообщение (рис. 6.5). 
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Рис. 6.5. Сохранение отредактированной записи о товаре и вывод 
подтверждающего сообщения 


Добавление проверки достоверности 


Как всегда, не стоит забывать о проверке достоверности введенных данных. Пока 
что беспрепятственно можно вводить пустые имена товаров и отрицательные цены. 
Мы исправим это таким же образом, как и при реализации проверки достоверности в 


361рр1па9П0еЁа11$ в главе Б. 

Добавьте в класс Рго@ись код, реализующий интерфейс тратаекгогТиго: 
риЮ11с с1азз РкоаисЕ : ТРафаЕггогТиЕо 
{ 

// .-. остальной код оставить без изменений ... 

риб11с зеЕ1па Е613[зЕг1па ргорМаме] 

{ 

деЕ { 


1Е ((ргорМаше == "Маше") && зЕг1п9.1$М№11ОтЕпруу (Маме) ) 
тебогп "Р1еазе епёег а ргодосе папе"; 


ТЕ ((ргорМаше == "РезсттрЕтоп") 5& ЗЕк1па. Т5М№11ОтЕтреу (Резст1ре1оп) ) 


теЕогп "Р1еазе епбег а Чезст1ре1опи; 
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} 


руб11с зЕг1па Еггог { деф { гебоги по11; } } // Не обязательно 


} 


1Е ((ргорМаше == "Рг1се")} && (Рг1се < 0)) 


} 


теёигп "Рг1се пшизЕ поЁ ре педае1уе"; 
1Е ((ргорМаше == "Сабедогу") && зЕг1ра. 15М№11ОгЕпр®у (Саседогу) } 

тебогп "Р1еазе зрес1ЁРу а саеедогу"; 
тебиги по11; 
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Интерфейс ТрафаЕтгоктпЕо будет обнаружен и использован системой привязки 
модели АЗРМЕТ МУС. Поскольку шаблон представления Еа1®.азрх визуализируется 
вспомогательным методом НЕп1.\а11Чат1опМеззаде() для каждого свойства моде- 
ли, любое сообщение об оптибке будет отображаться рядом с элементом управления, 
в котором обнаружена ошибка (рис. 6.6). (Это альтернатива вспомогательному методу 
НЕ .Уа11Ча&1опбиптаку (), который служит для отображения всех сообщений в одном 


месте.) 


о Вы 
| 4. (Е Нар/есиь 
| 


ЕЧИ Сгееп Кауак 


{ Мале: Оиееп КауаК 


ам мана ы 
| В : 
| 


: Саедоту: 


Ривазе эресйу а сайесогу, } 


Зае  Сапее! апа ета то 5 


И ы 


Рис. 6.6. Правила проверки достоверности теперь дей- 
ствуют, а сообщения об ошибках отображаются рядом с 
соответствующими элементами управления 


Можно также обновить 591РгодисеВероз1еогу, обеспечив гарантию, что он ни- 
когда не сохранит неверный экземпляр Ргодис в базе данных, даже если в будущем 
этого потребует некоторый некорректно функционирующий контроллер. Добавьте к 
31 РгоаисЕ зВероз1{огу новый метод ЕпзигеУа119 () и обновите его метод Зауергодис® (), 


как показано ниже: 


рую11с уо1а бауеРгодис® (Ргодис® ргодисе) 


{ 


} 


Епзиге\а114 (ргодасЕ, "Мапе", "Безсг1ре1оп", "Саседогу", "Рг1се"); 
. остальной код оставить без изменений ... 


// 


руЮ11с уо1а бауеРходисе (Ргодис® ргоаис®) 


{ 


Епзиге\а11а (ргоаосе, "Маме", "Безсг1ре1оп", "Сафедогу", "Рг1се"); 
. остальной код оставить без изменений ... 


// 
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рефуафе уо14 Епзиге\а119 (ТРабаЕккохТи6о уа11Чафсаю1е, рагатз зЕк1та[] ркорек1е5) 
{ 
1Е (ргореге1ез.Апу(х => уа11ЧафаБ1е[х|] != пи11)) 
ЕВком пех Тпуа11ЧОрега&1опЕхсер®1 от ("ТНе оБфесе 15 1пуа114."); 
// недопустимый объект 


} 


Создание новых товаров 


Возможно, вы уже заметили, что экран со списком, предназначенный для админи- 
стратора, содержит ссылку АДА а пем/ ргодис{ (Добавить новый товар). Сейчас щелчок 
на ней вызывает оптибку 404 МоЁ Еоипа (не найдено), потому что ссылка указывает на 
метод действия Сгеаге, который еще не существует 

Давайте создадим метод действия Стеафе(), который будет добавлять новые объ- 
екты Ргодис®. Все, что для этого потребуется — визуализировать чистый новый объ- 
ект РгодисЕ на существующем экране редактирования. Когда пользователь щелкает на 
кнопке бауе (Сохранить). существующий код должен сохранить новый объект РкодисеЕ. 
Таким образом, чтобы визуализировать пустой объект Ргодис® в существующем пред- 
ставлении /У1еиз/Адт1о/ЕЯ1е .азрх, добавьте в Аат1 пСопЕхо11ег следующий код: 


риб11с УтемВези1Е Сгеахте () 
{ 
геЕигп У1ем ("Е а1е", пеи Ргоаос® ()}; 


} 


Разумеется, эту реализапию можно предварить соответствующим модульным тес- 
том. Метод Сгеате () не визуализирует своего представления по умолчанию, а вместо 
этого визуализирует существующее представление /\У1енз/Ади1п/ЕЯ1+ .азрх. Это пока- 
зывает, что для метода действия совершенно приемлемо визуализировать представле- 
ние, которое обычно ассоциировано с другим методом действия, но если вы запустите 
приложение, то обнаружите, что это также иллюстрирует связанную с этим проблему. 

Обычно ожидается, что представление /У1еиз/Ади1р/ЕЯ1е.азрх визуализирует 
НТМГ-форму, которая посылает данные действию Еа1{ контроллера АдиаиСопего11ег. 
Однако /У1емз/Аат1п/Е91е.азрх визуализирует свою НТМГ.-форму вызовом вспомога- 
тельного метода НЕт1.Веч1пРоги() без передачи ему параметров, а это на самом деле 
означает, что форма должна передать данные по ОБТ, который посетил пользователь. 
Другими словами, при визуализации представления Е41% из действия Сгеафе форма 
НТМГ отправит данные действию Сгеахте, а не Еа1е. 

В этом случае необходимо, чтобы данные формы передавались действию Еа1*, по- 
скольку в него была помещена логика сохранения экземпляров Ргодис+ в репозитории. 
Модифицируйте /\1емз/Адпап/ЕЯТЕ . азрх, явно указав, что форма должна отправлять- 
ся действию Еа1е: 


<% 05119 (НЕм1.Вед1пРоги ("ЕЯ 4", "Адтзю")) { $%> 


Теперь функциональность Сгеафе будет работать правильно, что можно видеть на 
рис. 6.7. Проверка достоверности также будет работать, так как она закодирована в 
действии Еа1е. 


Удаление товаров 


Удаление товаров столь же тривиально. На экране списка товаров для каждого това- 
ра уже предусмотрена ссылка на пока что не реализованное действие Ре1еее. 
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Рис. 6.7. Добавление нового товара 


Тестирование: действие ре1ефе 


Если вы управляете разработкой с помощью тестов, потребуется написать тест, утверждающий 
необходимость реализации метода действия ре1ете (). Метод Бетеее () должен вызывать не- 
который метод удаления товара на интерфейсе тРгодисЕзВероз1еогу. Код теста может вы- 
глядеть следующим образом: 
[ТезЕ] 
рую11с уо1а Бе1еёе АсЕ1оп Бе1ефез Рго@исеЕ Твеп ВеЧ1гесе$ То Тпаех () 
{ 
// Подготовка 
АдитпСопего11ег сопЕго11ег = пем Ади1пСопЕго11ет (поскВероз .ОЮ]ес®); 
РгоЧисЕ рго924 = поскВероз.ОЮ]есе.Ргодисе$ .ЕР1гз® (р => р.РгодисЕтТЬ == 24); 
// Действие: попытка удаления товара 24 
Ведлгес®ТоВопЕеВезо1& гези1Е = сопёго11ег.Бе1еке (24); 


// Утверждение 
Аззеге.АгеЕаиа1 ("Тпаех", гези1е.ВоцееУа1иаез ["асЕ1оп"]); 
АззегЕ.АгеЕаиа1 ("Ргодасе 24 Ваз Бееп Че1ефе@Я", // Товар 24 удален 
сопЕго11ег.Тепррака ["пеззаде"]); 
поскВероз .Уег1 Ру (х => х.Бе1есеРго@осе (ргоа24)); 
} 


Обратите внимание на использование метода .Уег1Еу() фиктивного репозитория для про- 
верки того, что АдЗи1пСопЕго11ег действительно вызвал Бе1ефеРгоансЕ () с корректным 
параметром. Этот метод также проверяет факт сохранения соответствующего уведомления в 
ТепрПафа["пеззаае"] (вспомните: мастер-страница /У1еиз/5Вагеа/Адт1т .Мазеег уже 
умеет отображать сообщения подобного рода}. 


Чтобы все это заработало, прежде всего, понадобится добавить в интерфейс 
РгодисезВероз16огу метод удаления: 


рир11с 1пЕегЕасе ТРгодисЕ$Вероз1огу 

{ 
1ТОцегуаю1е<Рго@ос®> Ргодисез$ { аеё; } 
Уо1Я ЗауеРго@исе (РгоасЕ ргодис®); 
уо1а Бе1ефеРкоаиос® (РходисЕе ргодисЕ); 
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Ниже показана реализация метода для 541 РгодисЕ$Вероз16оту (в ГаКе?РгодисеВероз1+оку 
можно просто сгенерировать исключение МоЕТир1етепеедЕхсер® 1 оп): 


руЮ11с уо1а Бе1ебеРгодисе (РгодисЕ ргодисе) 


{ 
ргоднсЕзТа1е .ПБе1ебеопбирт1® (ргодисЕ) ; 
ргоаисе$Таю1е .СопЕех®е. бир ЕСвапаез (); 
} 


Ссылки Бе1е{е на экране списка товаров уже созданы. Все, что осталось сделать — 
реализовать метод действия по имени Ретеке (). 

Чтобы добиться компиляции и прохождения теста. реализуйте метод действия 
Ре1ефее() на Адт1пСопего11екг, как показано ниже. Результат работы этой функцио- 
нальности показан на рис. 6.8. 


рур11с Веа1гесеТокоиЕеВези1Е Бетеке (1пЕ ргоаисета) 
{ 
Ргоаис® ргоаисЕ = (Его р 1п ргходисЕзВероз1+огу.Ргодисез 
"беге р.РгодасЕтр == ргодисета 
зе1есЕ р) .Р1гзЕ(); 
ргоансЕВероз1еогку.БетеееРгодись (ргодисЕ); 
Тетррабка ["пеззаде"] = ргодис®.Маме + " Баз Бееп детекеа"; 
теЕагп Вед1гесЕТоАсетоп ("Траех"); 
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Рис. 6.8. Удаление товара 


На этом реализация СКОР-функциональности управления каталогом завершена: 
имеется возможность создавать, читать, обновлять и удалять записи Ргодис+. 


Защита средств администрирования 


Наверняка вы обратили внимание, что если развернуть приложение прямо сейчас, 
то любой сможет посетить страницу Бер: //сервер/Ади1и/Тпадех и внести беспорядок 
в каталог товаров. Вы должны предотвратить это, защитив доступ к Ади пСопего11ег 
с помощью пароля. 
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Настройка средства Рогт$ АшпеписаНоп 


Платформа АЗРМЕТ МУС построена на основе АЗРМЕТ, поэтому вы автоматически полу- 
чаете доступ к средству аутентификации с помощью форм АЗРМЕТ Еогтз Аи епйсаНоп — 
универсальной системе отслеживания зарегистрированных пользователей. Ее можно 
подключать к широкому диапазону пользовательских интерфейсов входа в систему и хра- 
нилищ регистрационных данных, в том числе и специальных. Более подробная информа- 
ция о Еогп$ Аи епНсаНоп будет дана в главе 15, а пока давайте воспользуемся ее про- 
стейшим способом. Откройте файл мер . сопЕ1 д и найдите в нем узел <апБепЕ1сае1оп>: 

<апВепЕлсаЕлоп тоае="РГогтз"> 


<Еогтз 1одлю0у1="-/Ассоцие/ТочОп" Е1меоце="2880"/> 
</ацЕБерЕ1салопт> 


Как видите, новые приложения АЗРМЕТ МУС уже используют Еогз Аи епнсаной 
по умолчанию. Параметр 1091101 сообщает Роз Аифеп@саНоп. что при входе в сис- 
тему пользователь должен быть перенаправлен на /Ассоире/ТЪодоп (при этом должна 
быть построена соответствующая страница входа). 


На заметку! Еще одним популярным методом аутентификации является \Мпаомз Ашиеписавоп 
(аутентификация М/паом5), при котором предполагается, что за определение контекста безо- 
пасности каждого НТТР-запроса отвечает веб-сервер (1$). Это удобно при разработке прило- 
жений для корпоративной сети, когда сервер и все клиентские машины являются частью од- 
ного домена \/паомз. Приложение сможет распознавать посетителей по их регистрационным 
записям в домене М/пЧом и ролям в АсНуе Опесюгу. 


Однако МИпаом5 АшепйсаНоп не особенно подходит для приложений, расположенных в пуб- 
личной сети Интернет, поскольку там нет такого контекста безопасности. Именно позтому не- 
обходимо выбирать метод Гоит$ Ашнепйёсаноп, который полагается на другие средства аутен- 
тификации (например, собственную базу данных регистрационных имен и паролей). Средство 
Рогт$ АитепйсаНноп запоминает факт регистрации посетителя в сооКе-наборах браузера. Это 
как раз то, что требуется для приложения Зрой${юге. 


Шаблон проекта АЗРМЕТ МУС предлагает рекомендуемую реализацию АссоипСопЕхо11ег 
(с действием Ъод0п, по умолчанию доступным на /Ассопп+ /1030п), которая для управ- 
ления именами и паролями пользователей использует ключевое средство членства 
АЗРМЕТ. Более подробные сведения о членстве и его применении в АЗРМЕТ МУС вы 
узнаете в главе 15. Однако для приложения, рассматриваемого в настоящей гла- 
ве, такая тяжеловесная система будет излишней. В главе 4 вы уже удалили началь- 
ный АссоопЕСопего11ет из проекта. Теперь вы замените его простой альтернативой. 
Обновите узел <апвепе1сае1оп> в файле мер. сопЕ1 9: 


<ааВепЕ1саЕ1от пойе="Еогтз"> 
<Еогтз 10о91п0т1="-/АссоипЕ/ТочОр" Елмеоце="2880"> 
<сгедепе1а1$ раззмогЯЕогта*="$НА1"> 
<изех папе="адилт" раззиога="е9Ее51Е94еа4аьЕ5445Е2:56957188Ь9аБее436е" /> 
</схедепЕ1а1з> 
</Еогтз> 
</апеБепЕ1саелоп> 


Хотя большинство приложений, использующих Роппз Аи епНсаНоп, хранят регист- 
рационную информацию в базе данных, здесь мы обходимся более простым решением, 
конфигурируя жестко закодированный список имен и паролей пользователей. В настоя- 
щее время этот список включает единственное имя пользователя — адили с паролем 
зузе1еск (значение е9Ее51Е... — это хен-значение ЗНА1 строки пузесте*). 
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Совет. Дает ли какие-то преимущества хранение хешированных паролей вместо паролей в виде от- 
крытого текста? Да, однако небольшие. Это затрудняет любому, кто читает файл чеЪ. сопЕ 19, 
использовать найденные там регистрационные записи (ему придется восстанавливать строку 
по хеш-значению, что, в зависимости от надежности хешированного пароля, либо очень трудно, 
либо вообще невозможно). Если вы не беспокоитесь, что кто-то прочитает файл меЪ . сопЕ1 9 
(например, имея уверенность, что никто не получит доступа к серверу), то можете задать па- 
роли в виде простого текста, установив раззмогаЕогтаЕ="С1еах". Большинства прило- 
жений это не касается, так как в них регистрационные записи вообще не будут храниться в 
мер. сопЁ19; обычно они записываются в базу данных (соответствующим образом хеширован- 
ные и зашифрованные). За подробными сведениями обращайтесь в главу 15. 


Использование фильтра для 
принудительной аутентификации 


Итак, средство Еогллз АиПенйисаНоп сконфигурировано, но пока не дает никако- 
го эффекта. Приложение по-прежнему не запрашивает регистрацию пользователя. 
Принудительного включения аутентификации в начало каждого метода, который тре- 
буется защитить, необходимо поместить следующий код: 


1Е (!Ведаез® .ТзАиЕБепЕ1сафеа) 
ЕогтзАцерепе1сае1опт.ВеЯ1кесЕТотод1пРаде (); 


Это будет работать, но приведенные две строки кода придется вставлять в каждый соз- 
даваемый метод действия для администратора. Что если вы где-то забудете это сделать? 

В состав АЗРМЕТ МУС входит удобное средство, которое называется фильтрами. 
Это атрибуты „МЕТ, которыми можно снабдить любой метод действия или контроллер, 
внедрив некоторую дополнительную логику в конвейер обработки запросов. Существуют 
разные типы фильтров, которые работают на разных стадиях конвейера: фильтры дей- 
ствий, фильтры обработки ошибок, фильтры авторизации. Для каждого типа. предусмот- 
рена реализация по умолчанию. Дополнительные сведения об использовании каждого 
типа фильтров, а также о создании собственных фильтров, можно найти в главе 9. 

Пока что можно применять фильтр авторизации по умолчанию? — [дофьог1=е]. 
Просто декорируйте класс АЗилиСопеко11ех атрибутом [Аивог1 те]: 


[АцеВохг12е] 
рию11с с1азз АаплиСопетго]11ех : Сопехго11ег 
{ 

По 


Совет. Фильтры можно присоединять к индивидуальным методам действий, но присоединение их 
к самому контроллеру (как в этом примере) обеспечивает их применение ко всем методам 
действий данного контроллера. 


Какой эффект это дает? Если вы теперь попытаетесь зайти на /Ади1и/тиаех (или 
обратиться к любому методу Аат1пСопетго11ехт], то получите сообщение об ошибке, по- 
казанное на рис. 6.9. 


? Как вы должны помнить, под аутентификацией понимается идентификация пользователя, 
в то время как под авторизацией — определение того, что разрентено делать конкретному 
пользователю. В рассматриваемом простом примере обе концепции объединяются в единое 
целое: мы говорим, что посетитель авторизован использовать АбилиСопехо11ех при усло- 
вии, что он аутентифицирован (те. зарегистрирован). 
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Рис. 6.9. Пользователь, не прошедший аутентификацию, перенаправляется 
на /АссоопЕ/ТодОп 


Обратите внимание на поле адреса, в котором находится следующая подстрока: 

/Ассоппе/ЪодОп?Вееитр0Ох1=%2ЕАдиаи$2Етпаех 

Она говорит о том, что средство Еогтиз Ан епнсанон перенаправило посетителя на 
ОКЕ, который был сконфигурирован в зеЪ.сопЕ1 а (при этом запись исходного запро- 
шенного ОК! сохраняется в параметре ветатп0т1 строки запроса). Однако пока еще нет 


ни одного зарегистрированного класса контроллера для обработки запросов этого ОБТ, 
поэтому фабрика \1пазогСопего11егЕасеогу генерирует ошибку. 


Отображение приглашения на ввод 
регистрационных данных 


Следующим шагом будет обработка этих запросов для /Ассоип+/ ТоаОв, для чего по- 
надобится добавить контроллер по имени АссоипЕСопеко11ех с действием тод0п. 


1. В классе АссоспЕСоп+тго11ех должен быть метод под названием ЪодОл (), обраба- 
тывающий запросы СЕТ. Он визуализирует представление с приглашением вве- 
сти имя и пароль. 


№ 


Должна быть предусмотрена еще одна перегрузка ТодОп (), которая обрабатывает 
запросы РО$Т. Эта перегрузка будет обращаться к Еогилз АилеписаНоп для про- 
верки достоверности пары “имя/пароль”. 


3. Если регистрационные данные действительны, средство Еогтз АиейнсаНон бу- 
дет уведомляться о том, что посетитель должен считаться вошедшим (оббеа 11), 
при этом посетитель будет перенаправлен на ОВГ. который изначально иниции- 
ровал фильтр [АбБог1 те]. 


4. Если введены неверные регистрационные данные, приглашение на ввод име- 
ни и пароля будет показано снова (с соответствующим примечанием “Тгу абайл” 
(Повторите попытку)). 
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Чтобы реализовать описанную выше функциональность, создайте новый контроллер 
по имени АссоппЕСопЕхго11ех со следующими методами действий: 


рур11с с1а55 АссоипЕСопЕго11ех : СопЕго1Лех 
{ 
[АссербУетЬз (НЕЕрУетрз .Сеф) ] 
ру611с УлемВези1Е Тод () 
{ 
хебити У1ем(); 


} 


[АссереУетЬз (НЕЕрУетЬз .Роз+) ] 
рУБ11с АсЕлопВези1Е ГодОр (36 тата паше, зЕг1пд раззмог, зЕт1па кефогпОт1) 
{ 
ЧЕ (РохизАцЕЬере1сае1оп.АнеБере1сафе (паше, раззмога)) { 
// Назначить место перенаправления по умолчанию, 
// если оно не установлено 
тебакпгОу1 = гебагпОу1 2? 0у1.Аселог ("Траех", "Адили"); 
// Установить соокле-набор и выполнить перенаправление 
РогизАиБепе1 сае1оп . Зе АцЕЬСооК1е (паше, ЁЕа15е); 
хебригп Кед1тес® (хеботп0т1); ; 
} 
е1зе { 
Утеирафа ["1аз1091пРа11еа"] = $хие; 
тебатп Улем(); 


} 


Для этих методов действий тодОп() также потребуется соответствующий шаблон 
представления. Добавьте его, щелкнув правой кнопкой мыши внутри метода ГодОп () и 
выбрав в контекстном меню пункт АДа \Мем/ (Добавить представление). Снимите отмет- 
ку с флажка Сгеае а эхопоу {уред мем (Создать строго типизированное представле- 
ние), поскольку для такого простого представления строгая концепция модели не нуж- 
на. В качестве мастер-страницы укажите - /У1емз/5Бахед/Адили .Мазфег. 

Ниже приведена разметка, необходимая для визуализации простой формы входа: 


<%@ Раде Т1Е1е="" Тапдзаде="С+" МазфехгРадеЕг11е="- /У1емз /5Ъагеа/АЯт1т .Мазтсех" 
ТпБег1Ез="бузфет. Мер .Мус.У1емРаде" %> 

<азр:СопеепЕ СопеепеР1асеНо1аеттр="Т1{1еСопфеп®" хипаЕ="зетует"> 
Аа : Тод ш 

</азр:СорфепЪ> 


<азр:СопЕепЕ СопЕепЕР1асеНо1аегТр="МалпСопееп®" гипаф="зетуег"> 
<61>109 1п</61> 


<% 1Е( (6001?) Улемрафа ["ТазЕоч1пРа1]1е@"] == сгое) { %> 
<Члу с1аз5="Меззаде"> 
Зокку, уойг Тод1п абфептрЕ Еал1еа. Р1еазе ку адалт. 
</алу> 
<% } %> 


<р>Р1еазе 109 1п Бо ассезз ЕБе ади1п1зЕкае1уе агеа:</р> 
<$ из1лпа (НЕт1 .Вед1пЕогт()) { %> 
<алу>Годлп паше: <%= НЕ] .ТехЕВох ("папе") %></91у> 
<91у>Раззмога: <%= НЕи1 .Раззмога ("раззмога") %></а1\> 
<р><1прае Еуре="зори1е" уа]пе="Тод 11" /></р> 
<$ } %> 
</азр:СопЕеп®> 
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Этот код будет обрабатывать попытки входа в приложение (рис. 6.10). После ввода. 
правильных регистрационных данных (те. адт1и/тузе1ес+) посетителю будет передан 
соо1е-набор аутентификации и разрешен доступ к методам действий Аатапсопехо1 ег. 


Реа5е 109 #1 0 ассе5$ {Пе аду чание агеа: 


Тод пате; | 
Равёзуюга: 


Гот 


Рис. 6.10. Приглашение на вход (визуализировано 
с использованием /\У1емз /Ассоире/ТочОп.азрх) 


Внимание! При отправке регистрационной информации из браузера на сервер ее лучше зашиф- 
ровать с помощью $1 (т.е. передавать по протоколу НТТР$). Поскольку встроенный веб-сер- 
вер Мзиа} Зи ю не поддерживает $551, потребуется соответствующим образом настроить веб- 
сервер (этот вопрос в книге не рассматривается). Подробные сведения о конфигурировании 
$$ можно найти в документации по И$. 


УмФ— Ц 


Тестируемость метода Год1л () 


При попытке написать модульные тесты для Год1п() вы столкнетесь с проблемой. В ны- 
нешнем состоянии код непосредственно связан с двумя статическими методами класса 
РогизАЕВепЕ1саЕ1оп (АцЕБепЕ1сате () и ЗеклиЕЬСооке () }. 


В идеальном случае модульные тесты должны использовать какой-то фиктивный объ- 
ект ГогизАиеБепЕ1саЕ1оп; тогда они смогут протестировать взаимодействие тод1п() со 
средством Роптз Ашепнсайоп (например, проверяя вызов Зе АнеьСоок1е () , только когда 
АлтрепЕ1сафе () возвращает ехие). Однако АР!-интерфейс Ропт$ Аинеписаноп построен на 
основе статических членов, поэтому имитировать его непросто. Средство Еогт$ Амнеписаноп — 
довольно старая часть кода, которая, в отличие от современного каркаса МУС Егатемогк, просто 
не проектировалась с учетом тестируемости. 


Обычный способ сделать нетестируемый код тестируемым состоит в том, чтобы поместить его в 
оболочку интерфейсного типа. Класс, который реализует интерфейс, создается простым делеги- 
рованием всех вызовов первоначальному коду. Например, поместите следующие типы в любое 
место проекта Меьот: 


22011с 1пеегЕасе ТЕогизАсеь 


Боо1 АцеБепЕ1сате (5Е:1п9 пате, зЕт1лпа раззмога); 
уофа ЗерАцЕВСоокле (36119 пате, 6оо1 регзазеепь); 


2211с с1азз РЕогтзАиЬИгаррег : ТЕогизАйеЬ 


24211с 6оо1 АцБепе1саее (5т1па паме, 5Ег1п9 раз$мога) 


гесагп РогизАйБепЕ1сае1от .АпеБепе1сате (пате, раззиога); 
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рую11с уо1а зеёаАцЕБСоокле (зЕх1па паце, Б6оо1 регзазфепь) 
{ 


РогизАисрепе1саЕ1оп . ЗеёАсЕрСоокКте (паме, регз1зепф); 
} 

} 

Здесь тТЕогизАс В представляет методы Ропт$ АМЛеписаноп, которые необходимо вызывать, 

ЕогизАчеЬИгаррег реализует его, делегируя его вызовы первоначальному коду. Почти так же 

средство Ропт$ Аиепйсаноп делается тестируемым в стандартном шаблоне АссоцпЕСопего11ех 

проекта АЗР. МЕТ МУС (который был удален в главе 4). 

Фактически это тот же самый механизм, который использует Зузфет. Иер .АБзЕхасЕ1опз для 

того, чтобы сделать тестируемыми старые классы контекста АЗР.МЕТ (вроде несркеаиез®), оп- 

ределяя абстрактные базовые классы (например, НЕЕрВечиезЕВазе) и подклассы (например, 

НесрВеачезЕИтаррет), которые просто делегируют исходный код. В МюгозоЁ решили приме- 

нять абстрактные базовые классы (с заглушками в качестве реализаций для каждого метода) 

вместо интерфейсов, чтобы после наследования от них можно было переопределить только не- 
обходимые методы (в случае с интерфейсами должны быть реализованы все методы). 

Таким образом, передать экземпляр ТгохтзАнеЬ методу Тод1п () можно двумя способами. 

« Используя контейнер С. Интерфейс тЕогизАифь можно зарегистрировать как компонент 
ЮС (с РохизАчЕВИгаррег, сконфигурированным в качестве его активного конкретного типа) 
и затем сделать так, чтобы АссоирЕСопехо11ех требовал передачи ТЕогизАить в парамет- 
ре конструктора. Во время выполнения фабрика илпазотСопЕто11ехЕасбогу позаботится о 
предоставлении экземпляра ЕоттзАцЕЬИгаррег. В тестах вполне достаточно будет фиктив- 
ного экземпляра тРогизАсеь в качестве параметра конструктора АссоспЕСопехо11егк. 

« Используя специальное средство привязки модели. Для интерфейса тгогизАчЕВ мож- 
но создать специальное средство привязки модели, который просто возвращает зкземпляр 
ЕогизАцЕЬИгаррек. Как только зто специальное средство будет зарегистрировано (аналогич- 
но регистрации СагЕМоде1В1пдех в главе 5), любой из методов действий сможет затребовать 
объект ТЕоттзАнЪ в качестве своего параметра. Во время выполнения специальное средство 
привязки модели предоставит зкземпляр ГохтзАзеЬИгаррег. В тестах достаточно будет фик- 
тивного экземпляра тгохизАотЪ в качестве параметра соответствующего метода действия. 


Оба подхода одинаково хороши. Если вы интенсивно используете контейнер оС, то можете пред- 
почесть первый вариант (преимущество которого в том, что ГохтзАзЕЪИтаррег можно заменить 
другим механизмом аутентификации, даже не компилируя повторно код). В противном случае 
достаточно удобным будет подход на основе специального средства привязки модели. 


Загрузка изображений 


Разработка приложения Зро{зюоге завершается реализацией несколько более слож- 
ного средства: предоставление администраторам возможности загружать изображения 
товаров, сохранять их в базе данных и отображать на экранах со списком товаров. 


Подготовка модели предметной области и базы данных 


Для начала добавьте в класс РгодисЕ два дополнительных поля, которые будут со- 
держать двоичные данные и их тип ММЕ (определяющий формат файла: УРЕС, СТЕ, 
РМ@ и тд.}: 


[Таф1е (Маше = "Ргоацсфз") ] 


рор11с с1азз РкоЧисе 
{ 


// Остальная часть класса не изменяется 
[Со1атп] роБ11с Буёе[] Тиадерафа { деф; зе*; } 
[Со1тп] роБ11с $зЕг1па ТиадеМ1меТуре { деф; зе; } 
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Затем с помощью Зегуег Ехрюгег (или ЗОТ. Зегуег Мапабетепе 55141) добавьте соот- 
ветствующие столбцы в таблицу Ргодисез базы данных (рис. 6.11). 


дбо.Ргодисе: Тов. 54. бропеблоге}* 
Собаения Мате `Баь Туре АН НЫ 
 Рисдисве Г 
Нате пуагсваи 00) 
Сезсе сть гезагораг 00) 
Се\еусгу эзагеРаг(30} 
Рисе ЗаснтзаН 6, 2} 
зала 
магонае. 50} 


Рис. 6.11. Добавление новых столбцов в Зегуег Ехрогег 


Сохраните обновленное определение таблицы, нажав комбинацию <СнН-5>. 


Выбор файла для загрузки 


Добавьте поле для загрузки файлов в /У1емз/Ааи1п/Ео4&.азрх: 
<р> 
Саседогу: <%= НЕш1 .ТехЕВох ("Сафедоку"} %> 
<91\><%= НЕ] .Уа11Чае1опМеззаде ("Сафедогу") %></41у> 
</р> 
<р> 
Ттасде: 
<% 1 (Мо4де1 .Тиадерафа == пи11) { $%> 
Мопе 
<$ } е1 зе { $> 
<419 зкс=”<$= Цк1.Ас1оп ("СееТтаде", "Ркодисьз", 
пем { Мо4е1.Ркоаисетр }) %>" /> 
<$ } $> 
<41у>0р1оа@ пем 1таде: <1прие вуре="Е11е" папе="Тиаде" /></азу> 
</р> 
<1приЕ Еуре="зири1е" уа1ае="5ауе" /> 
<!-- ... остальная разметка не изменяется ... --> 


Обратите внимание, что если отображаемый РкодисЕ уже имеет отличное от пи11 
значение Ттадерафа. то представление пытается отобразить это изображение, ге- 
нерируя дескриптор <1тд>, который ссылается на пока не реализованное действие 
Родосе СопЕго11ет по имени сееТтаде. Мы вернемся к нему очень скоро. 


Малоизвестный факт о НТМЁ-формах 


Интересен тот факт, что веб-браузеры правильно загружают файлы только в том 
случае, если дескриптор <Еогт> определяет значение по1Е1рагЕ /Еоги-дафа для атри- 


бута епскуре. Другими словами, для успешной загрузки дескриптор <Еохт> должен вы- 
глядеть следующим образом: 


<Еогм епсвуре="щи1ЕЁ1рах®/Еоги-Яафа">...</Еоги> 
Без этого атрибута епсфуре браузер передаст лишь имя файла, а не его содержи- 


мое — нам такое поведение ни к чему. Инициируйте появление атрибута епсфуре, об- 
новив вызов Нет1 .Вед1пРогт() в ЕЧ1е.азрх: 


<% из1иа (НЫ .ВедлиРоги ("ЕЯ1е", "Ада", ЕогиМефрвоа. Розе, 
пем { епсеуре = "шо1Е1рак®/Еоги-дафа" })) { $> 
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Конечные символы в строке выглядят подобно головоломке. Как это напоминает 
Рец... Но как бы то ни было, двинемся далыше. 


Сохранение загруженного изображения в базе данных 


Итак, теперь модель предметной области может сохранять изображения, иу вас есть 
представление. которое может их загружать. Значит, теперь необходимо обновить метод 
действия Еа1х (), реагирующий на запросы РОЗТ, контроллера АдтаиСопего11ех для 
приема и сохранения данных загруженного изображения. Это совсем не сложно: нужно 
просто принять загружаемое изображение как параметр метода НЕЕрРозкедЕ11еВазе и 
скопировать его данные в соответствующий объект товара: 


[АссерсУетЪз (НЕЕрУетЬЮ$.Роз+) ] 
ру611с АсЕ1опВези1Е ЕЯ1е (РходисЕ ргоайсе, НефрРозфеаг11еВазе 1таде) 
{ 
ТЕ (Моае15ъафе.Тз\Уа11а) { 
1Е (1таде != по11) { 
ркго@исе. ГаадеМ1теТуре = шпаде .Сопееп® Туре; 
рРгодмс®.Тиадерава = пеи Буфе [1таде .СопЕерЕЪепса В]; 
1паде .ТприебЕгеам.Веа@ (ргофис® .Ттадерафа, 0, 1щаде .СопеЕепТепроа В); 
} 
ргоаисЕВероз1огу.бауеРго@исе® (ргодис®); 


Конечно, понадобится также обновить модульный тест (если он есть}, который вызы- 
вает Еа1+ () , обеспечив передачу в параметре Ттаде некоторого значения (вроде по11)}; в 
противном случае возникнет ошибка компиляции. 


Вывод изображений товаров 


Все необходимое для приема загружаемых изображений и сохранения их в базе дан- 
ных реализовано, но пока что нет действия бееТтаде, которое будет возвращать гра- 
фические данные для вывода на экране. Добавьте в РкодасЕзСопего11ег следующий 
метод: 


ру611с Е11еСопфепЕВези1 СееТтаде (10 РгодисЕ Тр) 
{ 
РгодосЕ ргодисЕ = (Ехом р 11 ркодисЕзВероз1огу. Рко@асе$ 
уреге р.РгодосЕТр == Ркодосетр 
зе1есЕ р) .Елтз(); 
хебиги Е1Те (ркодис®. ТГтадерафа, ргодисе.ТтадеМм1тетуре) ; 


} 


В этом методе действия демонстрируется использование метода Е11е(), который 
позволяет возвращать двоичное содержимое непосредственно в браузер. Он позволя- 
ет отправлять низкоуровневый байтовый массив (как это делается для отправки дан- 
ных изображения в браузер], передавать файл с диска или подкачать содержимое 
Зузеет. то .5Егеат в НТТР-ответ. Метод Е11е () также является тестируемым: вместо пря- 
мого обращения к потоку ответа для передачи двоичных данных (что заставило бы эму- 
лировать контекст НТТР в модульных тестах), он на самом деле возвращает некоторый 
подкласс типа. Е11еВези1, свойства которого можно проверить в модульном тесте. 

Вот и все! Теперь можете загрузить изображения товаров, и они будут отображаться 
при повторном открытии товаров в редакторе, как показано на рис. 6.12. 
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Рис. 6.12. Редактор товара после загрузки и сохранения изображения товара 


Главной целью является вывод изображений товаров для потенциальных покупателей, 
поэтому соответствующим образом модифицируем /\У1емз/ЗЬахеа/ РгодисЕбонтату.а$сх: 


<Ч1у с1азз="16епт"> 
<% 1 (Мо4е1 .Ттадерафа != пи11) { $> 
<А1у з&у1е=" Е1оа&:1еЁе; пага1т-х1аве:20рх"> 
<На зкс="<%= 0к1.АсЕ1оп ("бееТтаде", "Ркодисез", 
пем { Мо4е1.Рко@исЕтр }) %>” /> 
</а1у> 
<% } %> 
<Ь3><%= Моде1.Мате %></53> 
... Остальная разметка не изменяется ... 
</91\> 


Судя по рис. 6.13, теперь объемы продаж должны значительно возрасти. 
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Рис. 6.13. Публично доступный список товаров после загрузки изображений 
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Упражнение: канал В$$ для сообщения о новых товарах 


В качестве финального расширения приложения Зро{5Зюге давайте реализуем В5$-канал для 
уведомления потенциальных клиентов о новых товарах, добавленных в каталог. Для зтого пона- 
добится решить следующие задачи. 


е Добавить в РгодисЕ новое поле Стеафера+е с соответствующим столбцом базы данных и 
атрибутом отображения ИМО тю $01. При сохранении нового товара его значение будет уста- 
навливаться в РасетТ1те . Мом. 


« Создать новый контроллер вззСопего11ет с действием по имени Еееа, которое опрашивает 
репозиторий товаров {в обратном хронологическом порядке) и визуализирует результаты в 
А$$-канал. 


® Обновить публично доступную мастер-страницу /У1еиз /5Багеа/$1+е .Мазфехк для уведом- 
ления браузеров о катале В$$, добавив ссылку на раздел <Беад>. Например: 
<11пК ге1="а]фехгпафе" Еуре="арр11саЕ1оп/хзз+хи1" 
Е1Е1е="Мем брохЕз5еоге рго@днсез" ргеЕ="ЬЕер: //уопгтзегует/тзз/ЕееЯ" /> 


Для справки ниже приведен вывод, который должен получиться в конечном итоге: 
<?хи1 уегз1оп="1.0" епсодлра="аЕЕ-8" 2> 
<гзз уегз1оп="2.0"> 
<сваппе1> 
<Е1Е1е>брогЕз5Еоге пеи ргодисез</&1ЕТе> 
<дезсг1рЕ1оп>Виу а11 Ве воетсезЕ пем зрогсз деаг</дезст1релор> 
<11пК>ВЕЕр: //зрогЕззбоге .ехатр1е .сом/</11тК> 
<1Еет> 
<Е1Е1е>Терпп1з гасаиес</Е1Е1е> 
<Чезст1рЕ1оп>Тдеа] Рог №1119 Еепи1$ ра113</дезси1релоп> 
<11пК>ЬЕЕр: //ехапшр1е . сом/$епп13</1лик> 
</1еет> 
<1ет> 
<Е1Е1е>Ьазег-до14Аейя Бом11пд Ба11</Е1Е1е> 
<дезсг1рЕлоп>А диагапееей зетлке, еуегу Елте</дезси1рЕлоп> 
<11пК>ЬЕЕр: //ехатр1е. сом/Еепр1ирои1119</11пКк> 
</1Сет> 
</сваппе1> 
</гзз> 


В главе 9 будет предложен пример метода действия, использующего АР!-интерфейс „МЕТ под 
названием ХРосимепе для создания данных В $$. 


Резюме 


На протяжении последних трех глав было показано, как использовать АЗРМЕТ МУС 
для создания реалистичного приложения электронного магазина. Этот расптиренный 
пример продемонстрировал многие средства каркаса (контроллеры, действия, пред- 
ставления, частичные представления, мастер-страницы и аутентификация Еопп$ 
Аи?епйсаНоп), наряду с связанными с ними технологиями (ГМО Фо ЗСТ. СазПе МУЯпазог 
для юС, МОпЁ и Мод для тестирования). 

Вы узнали, как, согласно рабочему потоку ТОО, модульные тесты управляют процес- 
сом разработки, и какую поддержку оказывает дружественный к тестам АР!-интерфейс 
АЗРМЕТ МУС. Вы также научились строить компонентно-ориентированную архитекту- 
ру приложения с четким разделением ответственности, которая сохраняет приложение 
понятным и легко сопровождаемым. 

В части 2 отдельные компоненты МУС ЕгатлехогК будут рассматриваться более под- 
робно, что позволит получить исчерпывающее предоставление об их возможностях. 


ЧАСТЬ || 


АЗРМЕТ МУС 
во всех деталях 


К этому моменту вам уже известно, для чего была спроектирована платфор- 
ма АЗР МЕТ МУС. Вы разобрались с ее архитектурой и проектными целями. 
Вдобавок вы опробовали ее на примере разработки реалистичного приложения 
электронного магазина. 

В этой части будут раскрыты все детали внутреннего устройства платформы 
АЗРМЕТ М\УС. Здесь вы найдете систематизированную документацию с описа- 
нием всех ее частей и возможностей, а также практические руководства и рецеп- 
ты реализации широкого диапазона прикладных средств веб-приложений. 


ГЛАВА 7 


Общее представление 
о проектах АЗРМЕТ МУС 


ройдя все этапы построения реалистичного приложения МУС под названи- 
ем ЭрогёЗ юге, вы попутно приобрели изрядный объем знаний о разработке на 
платформе АЗРМЕТ МУС. Однако это был лишь один пример, не охватывающий всех 
средств и возможностей МУС ЕгатехогкК. Для того чтобы восполнить недостающее, мы 
предложим более систематическое описание каждого аспекта МУС Егаюзеххогк. В главе 8 
будет рассматриваться базовая система маршрутизации. В главе 9 будет продемонстри- 
рованы возможности, доступные для построения контроллеров и действий. В главе 10 
внимание будет сосредоточено на встроенном механизме представлений АЗРМЕТ МУС. 
В остальных главах будут описаны другие задачи и сценарии веб-разработки. в том 
числе вопросы, связанные с безопасностью и развертыванием. 

Чтобы не упустить из виду даже мельчайшие детали каждого компонента МУС, сна- 
чала окинем взглядом общую картину. В этой главе мы рассмотрим общее устройство 
приложений МУС: структуру проекта по умолчанию и соглашения по именованию, ко- 
торым необходимо следовать. Вы получите полное представление о всем процессе обра- 
ботки запросов и узнаете, как все компоненты платформы работают вместе. 


Разработка приложений МУС в Миа! $и4о 


Во время установки АЗРМЕТ МУС выполняются следующие действия. 


® Вглобальном кэше сборок (САС) регистрируется сборка МУС Егапле\гогК под назва- 
нием бузеет.Мер.Мус.@а11, а ее копия помещается в каталог \Ргодгаш Е11ез\ 
М1стозоЕЕ АЗР.МЕТ\АЗР.МЕТ МУС 1.0\АззепЬ11ев. 


® Впапку \Соптоп7 \ ТРЕ, через которую АЗРМЕТ МУС интегрируется в \1зиа] Зла, 
устанавливаются разнообразные шаблоны. Вот что включают эти шаблоны. 


1. Шаблоны проектов для построения новых веб-приложений АЗРМЕТ МУС и тес- 
товых проектов (в подпапках Рго] есеТепрлафез\СЗБагр\Иеь\1033 и Тез+). 


2. Шаблоны элементов для создания контроллеров, представлений, частичных 
представлений и мастер-страниц через пункт меню АЯ Нет (Добавить эле- 
мент) (в подпапке Теептепртаеез \СЗВагр\Меь\МУС). 


3. Шаблоны Т4, генерирующие код для предварительного заполнения контрол- 
леров и представлений при их создании через пункты меню АДА СопоНег 
(Добавить контроллер) и Ааа Ме\м (Добавить представление) (в подпанке 
ГрепТепр1асез\СЗВагр\меь\МУС\Содетепр1акез). 
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® Добавляется набор файлов сценариев для регистрации файлового расшире- 
ния .шус на сервере П$. в случае, если планируется его использование (в пап- 
ке \Ргодгам Е11ез\МусгозоЕЕ АЗР.МЕТ\АЗР.МЕТ МУС 1.0\5ст1рЕз). Однако 
обычно вам эти сценарии не применяются, потому что расширение .пус обычно 
не должно появляться в ОВГ. Если все-таки это понадобится, расширения ОВГ 
можно зарегистрировать в диспетчере П$ Мапабег с графическим интерфейсом, 
как будет показано в главе 14. 


При желании можно отредактировать шаблоны \1зиа] 56а1о и внесенные измене- 
ния отразятся в ШЕ-среде. Однако для редактирования доступны только шаблоны ТА, 
генерирующие код, и вместо того, чтобы редактировать глобальные шаблоны, центра- 
лизованно представленные в \У1з0а] Зато, имеет больше смысла редактировать специ- 
фичные для проекта копии. которые можно поместить в систему управления исходным 
кодом. Подробнее о механизме шаблонов 14 и его применении в проектах АЗРМЕТ МУС 
можно узнать на сайте по адресу БЕЕр: / /Е1пуцг1 . сош/Т4пхс. 


Структура стандартного проекта МУС 


Когда в \У15иа] Эна ю создается совершенно новый проект веб-приложения АЗРМЕТ 
МУС, предоставляется начальный набор папок и файлов, показанный на рис. 7.1. 
Некоторые из этих элементов играют специальные роли, жестко закодированные в МУС 
ЕгаваехогК (и подчиняются предопределенным соглашениям об именовании), в то время 
как другие имеют характер простых рекомендаций относительно структуры проекта. 
Эти роли и правила описаны в табл. 7.1. 
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Рис. 7.1. Окно ЗоиНоп Ехрогег сразу после создания нового приложения АЗР МЕТ МУС 
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Таблица 7.1. Файлы и папки в стандартном шаблоне веб-приложения АЗР.МЕТ МУС 


Ым— 


Папка или файл 


Предполагаемое назначение 


Специальные полномочия 
и ответственность 


/Арр_Рафа 


ИБ 


/Соптепе 


/Сопего11ег$ 


/Моде1 $ 


Если используется файловая база данных 
(например, файл * .паЕ для ЗОЕ Зегуег 
Ехргез$ ЕЯ юп или файл * „ша для Мегозой 
Ассе55), она размещается именно в этой 
папке. Сюда также можно поместить другие 
файлы частных данных (например, * . хп], 
поскольку 1$ не не обслуживает файлы из 
этой папки. Тем не менее, можно получать 
доступ к ним из кода. Файловые базы данных 
на основе 501. не могут использоваться ни 

с одной из полноценных версий ЗО1 Зегуег 
(отличных от Ехргез$ Е@йюп), поэтому на 
практике они применяются редко. 


Здесь находится скомпилированная сборка 
„МЕТ веб-приложения МУС и все прочие 
сборки, на которые она ссылается (как в тра- 
диционном приложении АЗР.МЕТ \МебРопт$}. 


Это место для статических, публично 
доступных файлов (например, *.с55 
и изображения). 


Здесь находятся классы контроллеров (те. 
классы, унаследованные от Сопего11ех 
или реализующие ТСопеко11ег). 


Это место для размещения классов, пред- 
ставляющих модель предметной области. 
Однако во всех приложениях, за исключени- 
ем наиболее простых, модель предметной 
области лучше помещать в отдельный про- 
ект библиотеки классов С#. В этом случае 
папку /Моде1 з можно либо удалить, либо 
использовать не для полноценных моделей 
предметной области, а для простых презен- 
тационных моделей, которые существуют 
только для передачи данных от контроллеров 
кпредставлениям. 


Сервер И$ не обслуживает содержимое этой 
папки для внешнего мира. Если в системе ус- 
тановлена версия ЗСЕ Зегуег Ехргез$ ЕдЙюп, 
а строка подключения содержит 
АЕТасьорЕ11еКате= | Рафар1 гескогу 
|Мурафафазе .шаЕ, будет автоматически 
создана и подключена файловая база данных 
/Арр_Рата/Муратаразе. ша 


Сервер И$ рассчитывает здесь найти ваши 
сборки ВИ. Во время компиляции Миа! 
Зм0ю копирует в эту папку все сборки БЫ, 
на которые производятся ссылки (за исклю- 
чением тех, что находятся в глобальном кэше 
сборок (САС)). Сервер $ не обслуживает со- 
держимое этой папки для внешнего мира. 


Отсутствуют; это просто рекомендация. При 
желании эту папку можно удалить, но все 
равно нужно где-то хранить изображения и 
файлы С$$, и данная папка — вполне подхо- 
дящее место. 


Отсутствуют; это просто рекомендация. Не 
имеет значения, поместите вы контроллеры 
непосредственно в эту папку, в ее подпапку 
или куда-то в другое место проекта, потому 
что все они компилируются в одну сборку. 
Классы контроллеров также могут быть по- 
мещены в другие ссылаемые проекты или 
сборки. Первоначальное содержимое этой 
папки можно удалить (НопеСопЕго11еги 
АссоопЕСопего11ег) — они просто демон- 
стрируют, с чего можно начать. 


Отсутствуют; эту папку можно удалить. 


Папка или файл 
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Предполагаемое назначение 


Специальные полномочия 
и ответственность 


$сг1рёе5 


/У1емз 


/Улемз/5Звагеа 


/М1еиз/Меь. сопЕ19 


/РеЁац1е.азрх 


/С1офа1.азах 


Мер. сопЕ19 


Это еще одно место для размещения стати- 
ческих, публично доступных файлов, но пред- 
назначенное в основном для файлов кода 
Чама$спр! (*.3з). Файлы М1сгозоЕЕ*. 5 
предназначены для поддержки вспомога- 
тельных методов АЗРМЕТ М\С АЗах.*,а 

) ачеку* . } 3, необходимы в случае исполь- 
зования библиотеки {буету (см. главу 12). 


Здесь находятся представления (обычно 
файлы *.азрх} и частичные представления 
(обычно файлы *.азсх). 


Здесь находятся шаблоны представлений, 
которые не ассоциированы с определенным 
контроллером — например, мастер-ст- 
раницы (* .Мазфег) и любые совместно 
используемые представления или частичные 
представления. 


Это не главный файл меЪ . сопЕ19 Прило- 
жения. Он содержит только директиву, ин- 
структирующую веб-сервер не обслуживать 
файлы *.азрх из папки /У1еиз (так как 
они должны быть визуализированы контрол- 
лером, а не вызываться непосредственно как 
файлы * .азрх в МеБРогтз). Этот файл так- 
же содержит конфигурационные настройки, 
необходимые для того, чтобы стандартный 
компилятор страниц АЗРМЕТ АЗРХ правиль- 
но работал с синтаксисом шаблонов пред- 
ставлений АЗРМЕТ М\С. 


Этот файл не имеет особого отношения к 
АЗРМЕТ М\С, но необходим для совмести- 
мости с сервером И$ 6, которому требуется 
“страница по умолчанию” для сайта. Когла 
РеЁап1% .азрх выполняется, он просто пе- 
редает управление системе маршрутизации. 


В этом файле определен глобальный объект 
приложения АЗР.МЕТ. Его класс отделенного 
кода (/С1оба1 .азах.с$) — это место для 
регистрации конфигурации маршрутизации, 
а также для установки кода, который будет 


Отсутствуют, эту папку можно удалить. 
Однако если вы планируется использование 
вспомогательных методов Азах . *, то потре- 
буется ссылаться на файлы МусгкозоЕЕ* .-, 
расположенные в другом месте. 


По соглашению представления для класса 
контроллера Ху?СопЕго11 ег находятся в 
папке /\У1емз/Ху2. Представление по умол- 
чанию для действия РоботеЕв1 9 () класса 
Ху7Сопего1 Тех должно быть помещено 

в /АЛеи5/Хух/ПБобощееь1т9 .азрх 

(или /Улеиз/Ху2/Робощеев119.азсх, 
если он представляет элемент управления, 
ане целую страницу). Если изначально 
доступные классы БотеСопЕго11ег или 
АссоппЕСойе го] Тег Не используются, со- 
ответствующие представления можно удалить. 


Если файл /У1еиз/Ху2/Робомеев1т9. 
азрх (ИЛИ .азсх) не может быть обнару- 
жен, то следующее место, где будет про- 
изведен поиск — это /Улемз/ЗВагей/ 
Робопеет119 .азрх. 


Обеспечивает правильность компиляции и 
выполнения приложения (как описано в пре- 
дыдущем столбце}. 


Этот файл удалять нельзя, иначе приложение 
не будет работать под управлением сервера 
5 6 (хотя на сервере И$ 7, запущенном в 
режиме меогаед Рурейпе (Интегрированный 
конвейер) все будет в порядке). 


АЗР.МЕТ ожидает найти файл с этим именем, 
но не обслуживает его для внешнего мира. 


выполняться при инициализации или останове 
приложения либо при возникновении необрабо- 
танного исключения. Работает в точности, 

как файл С1оЪа1 .азах из АЗРМЕТ МебРогтз. 


В этом файле определена конфигурация 
приложения. Далее в этой главе мы еще по- 
говорим об этом важном файле. 


АЗРМЕТ (и 1$ 7) ожидает найти файл с этим 
именем, но не обслуживает его для внешнего 
мира. 
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На заметку! Как будет показано в главе 14, приложение МУС развертывается копированием 
большей части этой структуры папок на веб-сервер. Из соображений безопасности сервер 
15 не обслуживает файлы, полный путь которых включает мер .сопЕ1ч, Б1п, Арр_соде, 
Арр_С1офа1Везоигсе, Арр_Тоса1Везопгсез, Арр_ИеЮБеЕегепсе$з, Арр Рафа 
и Арр Вгоизегз, потому что в файле арр11са®1опНоз®.сопЕ19 определены узлы 
<ртадепбедтеп+>, скрывающие их. (Сервер ИЗ 6 также их не обслуживает, поскольку в нем 
имеется расширение |1$ЗАР! под названием азрпее Е11+ехг.а11, в котором жестко закодиро- 
вана их фильтрация.) Аналогичнём образом, сервер 1$ сконфигурирован на фильтрацию запро- 
СОВ *.азах, *.азсх, *. $1еетар, *.гезх, * ‚пар, * АЕ, *.1АЕ, *.сзрго] и ряда других. 


Перечисленные выше файлы создаются автоматически при создании нового веб- 
приложения АЗРМЕТ МУС. Кроме того, есть и другие папки и файлы, которые имеют 
специальное назначение для ядра платформы АЗРМЕТ. Все они описаны в табл. 7.2. 


Таблица 7.2. Дополнительные файлы и папки, имеющие специальное назначение 


Папка или файл Назначение 

/Арр С1оБа1Везоигсез Содержит файл ресурсов, используемый для локализации страниц 
/Арр_Тоса1Везоигсе$ \/еррогтз. Подробнее о локализации будет рассказано в главе 15. 
/Арр_ Вгомзегз Содержит ХМЕ-файлы „.юхоизег, описывающие способ идентифи- 


кации специфических веб-браузеров и их возможности (например, 
поддерживают ли они сценарии Зауа$сири. 


/Арр_ТВецшез Содержит “темы” \МеБРогте (включая файлы . $К1п), которые влияют 
на визуализацию элементов управления \МебРогтз. 


Последние из перечисленных выше файлов являются частью платформы АЗРМЕТ и 
не являются обязательными для приложений АЗРМЕТ МУС. За дополнительной инфор- 
мацией об этом обращайтесь к документации по АЗРМЕТ 


Соглашения об именовании 


Вы должны были заметить, что в АЗРМЕТ МУС предпочтение отдается соглашениям, 
а не конфигурации". Это означает, например, что явно конфигурировать ассоциацию 
между контроллерами и их представлениями не потребуется; вы просто следуете оп- 
ределенным соглашениям об именовании. и все работает. (Честно говоря, вам придет- 
ся конфигурировать довольно много настроек в файле меь . сорЕт д, но это в основном 
касается сервера ПЗ и ядра платформы АЗРМЕТ.) Несмотря на то что о соглашениях об 
именовании уже упоминалось ранее, давайте вспомним основные положения. 


® Классы контроллера должны иметь имена, заканчивающиеся на Сопего11ег 
(например, Ргодисе5Сопего11ет). Это жестко закодировано в РеРап1СопЕго11ег 
Расфогу: если вы не будете соблюдать это соглашение, класс не будет распознан 
как контроллер, и запросы к нему направляться не будут. Обратите внимание, что 
при создании собственной фабрики Т СопЕго11етРаскогу (см. главу 9) следовать 
этому соглашению не обязательно. 


® Шаблоны представлений (* .азрх, *.азсх) должны располагаться в папке 
/Утемз/имяКонтроллера. Не включайте сюда суффикс Сопего11ет — представ- 
ления для Ргодисе$Сопего11ег должны попасть в /У1емз/Ргодаскв, а не в 
/У1емз /РкобисеСорего11ек. 


! Эта тактика (как и фраза) — одна из знаменитых маркетинговых деклараций КоБу оп Вай&. 
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® Представление по умолчанию для метода действия должно называться по име- 
ни самого метода действия. Например, представление по умолчанию для дейст- 
вия Г15% контроллера Реодис®$Сопеко11ет должно располагаться в /Утеи5/ 
Ргодисе5/113Е.азрх. В качестве альтернативы можно указать имя представле- 
ния (например, возвращая У1еи ("Зоте\1еи")), после чего будет производиться 
поиск /\1еиз /Рходис® / бопе\1еи.азрх. 


® Когда представление по имени /У1еиз/РеобисЕ$/Ху? .азрх обнаружить не удает- 
ся, предпринимается попытка найти /У1емз/Ргодис®$/Ху2.азсх. Если и она не 
удается, ищется /У1еиз/5пагеЯ/Ху2 .азрх, а затем /У1еиз/5ВагеЯ/Хут.азсх. 
Это значит. что папку /У1емз/5Багеа можете использовать для хранения всех 
представлений, разделяемых между несколькими контроллерами. 


Все соглашения, касающиеся папок и имен, могут быть переопределены с исполь- 
зованием специального механизма представлений. В главе 10 будет показано, как это 
делается. 


Начальный скелет приложения 


Как показано на рис. 7.1, вновь создаваемые проекты АЗРМЕТ МУС не являются со- 
вершенно пустыми. Они уже оснащены встроенными контроллерами НопеСопего11ег 
и АссочиеСопего11 ег и несколькими ассоциированными с ними шаблонами представ- 
лений. В стандартные файлы проекта встроена довольно большая часть поведения. 


1. Контроллер НовеСопего11ег может визуализировать начальную страницу (Ноше) 
и страницу с описанием приложения (АБои{. Эти страницы генерируются с ис- 
пользованием мастер-страницы и темы с голубыми умиротворяющими тонами из 
файла С$$. 


2. Контроллер АссочпСопего11етх позволяет посетителям регистрироваться и вхо- 
дить в приложение. Он использует аутентификацию Рогтз АипеписаНоп с соо е- 
наборами для отслеживания входа каждого пользователя и средство членства 
(пешЪегзЫр) базовой платформы АЗРМЕТ для ведения списка зарегистрирован- 
ных пользователей. Когда кто-либо в первый раз нытается зарегистрироваться 
или войти в систему. средство членства создаст “на лету” файловую базу данных 
ЗОТГ, Зегуег Ехргезз. Если сервер ЭОГ. Зегуег Ехргезз не установлен или не запу- 
щен, средство членства работать не будет. 


3. Контроллер АссоипЕСопего11ет также включает действия и представления, ко- 
торые позволяют зарегистрированным пользователям изменять свои пароли. Для 
этого также применяется средство членства АЗР.МЕТ. 


Начальный скелет приложения представляет собой замечательное введение вустрой- 
ство приложений АЗРМЕТ МУС. Тем, кто только начинает работать с МУС Егавзехмотк, 
он помогает увидеть интересные особенности сразу же после создания нового проекта. 

Однако, маловероятно, что вы сохраните поведение по умолчанию без изменений. 
Исключением является ситуация. когда разрабатываемое приложение действительно ис- 
пользует средство членства АЗРМЕТ (описанное более подробно в главе 15} для ведения 
учета зарегистрированных пользователей. Большинство новых проектов АЗРМЕТ МУС 
можно начинать с удаления многих из этих файлов, как это делалось в главах 2 и 4. 


Отладка приложений М\С и модульные тесты 


Приложение АЗРМЕТ МУС можно отлаживать точно так же, как традиционное при- 
ложение АЗРМЕТ \еБЕогиз. Отладчик \1з0а1 Эба@ю 2008 практически не изменился по 
сравнению с прежними версиями, поэтому если вы хорошо с ним знакомы, можете про- 
пустить этот раздел. 
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Запуск отладчика Миа! Зоо 


Для запуска отладчика \Мзиа] Знаю просто нажмите <Е5> (или выберите пункт 
меню Бебио> {аи БеБидодта (Отладка>Начать отладку)). Когда это делается первый 
раз, будет предложено включить отладку в файле Иеь . сопЕ1с (рис. 7.2). 


агкоЕ Бе гов В ево слое Бесвизе Чебовдии 5 постера ей п Не УВВ сои 
зыфуса ПКЕ Чо? 


} Ве раде с 
Ном 


Басс пе ИвБ.сспЯ о 21 то епзЫе Чебысойо. 


В 

| 

В 

Е: 

| 4  ОеБооатеа наше Бе сна ев п сне доп Ме ребсте сайониа №е 
| > 3 еси 

|: ЖНаБ 5НЕ то а реобьсчоя епуйоситепь, 
В 
1 
В 
| 
} 
} 
: 


Ву ейфнит оеБасанта, Банвлаваи се Са4+Е5} 


Рис- 7.2. Приглашение Мвиа! Зи включить отладку страниц Ме Рогиз 


В случае выбора переключателя Мо@Ну Ше \МеБ.сопНо Ше ю епаШе дебидото 
(Модифицировать файл Мер . сопЕ19 для включения отладки) \У1зиа1 Зал@ю обновит узел 
<сотр11аЕ1оп> файла Ме. сопЕ1оа: 


<зузбет.мер> 
<сошр11а1оп Аебич="Екае"> 
</сопр11а1оп> 
</зузЕет.мер> 


Это значит, что шаблоны АЗРХ и АЗСХ будут компилироваться с отладочной ин- 
формацией. Это не повлияет на возможность отладки кода контроллеров и действий, 
однако в \1зиа1 За 1ю принят именно такой подход. Как показано на рис. 7.3, преду- 
смотрена отдельная настройка, которая влияет на компиляцию файлов .сз (напри- 
мер, кода контроллеров и действий) в самом графическом интерфейсе \У\1зиа! Зва@юо. 
Режим БеБиод (Отладка) должен выбираться вручную, так как \Мзиа! Зилд1о не делает 
это автоматически. 


Е; ЕР Метозой ‘Изна! нь 


Ре Е Мел  Редес ВыНа ыы тои Те  Уйоениь Неер 


Е 


Пт 2 т Е * ЕЕ ы Га +559 т! 5пуСРЫ 


] 

|| 

| Везде ры 
| Сопйбинаси Мападег... 
} 


| 
В 
| 
| 


Рис. 7.3. Для использования отладчика проект должен компилироваться в режиме БеБид 


На заметку! Для развертывания на рабочем веб-сервере должен использоваться код, ском- 
пилированный в режиме Нееазе (Выпуск). Вдобавок понадобится установить настройку 
<сопр11аЕ1оп дерид="Еа15е"> в файле Ме . сорЕ1ч рабочего сайта. Причины зтих дей- 
ствий будут подробно описаны в главе 14. 


После этого У1зиа1 Эа запустит приложение с отладчиком, подключенным к 
встроенному веб-серверу Мебреу .Меббегуег.ехе. Нужно будет только установить точ- 
ку останова, как будет описано ниже (в разделе “Использование отладчика”). 
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Подключение отладчика к серверу 15$ 


Если вместо использования встроенного веб-сервера \1зиа] Зл@1о создаваемое при- 
ложение запускается на сервере П$, функционирующем на машине разработки, отлад- 
чик можно подключить к П$. В среде \У1з0а! ЗнаАю нажмите комбинацию <СШ-+АН+Р> 
(или выберите пункт меню Бебид>АНасй ю Ргосе$$ (Отладка=Присоединиться к про- 
цессу)). В открывшемся окне АНаси т Ргосез$ (Присоединиться к процессу), которое по- 
казано на рис. 7.4, отьщите работающий процесс по имени иЗир .ехе (для версии П$ 6 
или 7) или азрпее ир.ехе (для версии И$ 5 или 5.1). После выбора соответствующего 
процесса щелкните на кнопке АНасй (Присоединиться). 


На заметку! Если рабочий процесс найти не удается, возможно, это потому, что вы имеете дело с 
Н$ 7 или работаете через подключение к удаленному рабочему столу (Ветое Безкюр}. В этом 
случае понадобится отметить флажок ЗНо\м/ ргосеззез т а! зезюп$ (Показать процессы во 
всех сеансах). Также следует проверить, действительно ли запущен рабочий процесс, открыв 
приложение в веб-браузере и щелкнув на кнопке обновления в \Мзиа! Эша. В среде Мипаоме 
\Мза с включенным средством контроля учетных записей (ЦАС} система Мзиа! Зо должна 
быть запущена в режиме повышения привилегий (если это не так, то после щелчка на кнопке 
АНасн будет выдано соответствующее предупреждения). 


Рис- 7.4. Присоединение отладчика \Мзиа! Зшео к рабочему процессу 1$ 6/7 


Подключение отладчика к среде выполнения тестов 


При выполнении болышого объема модульного тестирования вы обнаружите, что 
запускаете код в среде выполнения тестов, подобной графической среде МОпи, почти 
так же часто, как и на веб-сервере. Если тест неожиданно дает сбой (либо вопреки ожи- 
даниям проходит успешно), то вместо сервера И$ отладчик можно подключить к среде 
выполнения тестов. Удостоверьтесь, что код скомпилирован в режиме Оерцо, после чего 
в диалоговом окне АНасй тю Ргосе$ (открывающемся по нажатию <СШ+А!+Р>) найдите 
процесс среды выполнения тестов в списке доступных процессов (рис. 7.5}. 


дыаНаЫе РгосесвЕя 
Руссе и) Тине Туре 
псберабехе 25165 Пина - Чсерад х55 
3844 85 


Рис. 7.5. Подключение отладчика \Мзиа! Зи к графической среде МИпй 
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Обратите внимание, что в столбце Туре (Тип) показано, какие процессы выполняют 
управляемый код (те. код МЕТ). С помощью этого столбца можно быстро идентифици- 
ровать процессы, выполняющие ваш код. 


Удаленная отладка 


Если сервер П$ установлен и запущен на других ПК или серверах домена УЯпдо\уз, 
для которых настроены соответствующие полномочия отладки, можете ввести имя 
или ТР-адрес компьютера в поле Оца!ег (Квалификатор) и приступить к удаленной 
отладке. При отсутствии домена УЯвпдо\з измените значение в раскрывающемся спи- 
ске Тгапзрог (Транспорт) на Нетое (Удаленный) и выполняйте отладку по сети (пред- 
варительно сконфигурировав на целевой машине монитор удаленной отладки (Вешое 
Ребибятр МопНог) для ее разрешения). 


Использование отладчика 


Как только отладчик \У1з0а] Зла присоединен к процессу, можно останавливать вы- 
полнение приложения и смотреть, что оно делает. Для этого поместите на нужную стро- 
ку исходного кода точку останова (5геакрой®, щелкнув на ней правой кнопкой мыши 
и выбрав в контекстном меню Вгеакро=> тзет ргеаКрош\ (Точка останова=Вставить 
точку останова), нажав <Е9> или щелкнув в серой области слева от строки кода. Возел 
строки появится кружок красного цвета. Когда присоединенный процесс достигнет этой 
строки кода, отладчик остановит выполнение, как показано на рис. 7.6. 
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Рис. 7.6. Отладчик достиг точки останова 


Отладчик У1виа] Зн110 — очень мощный инструмент, Он позволяет читать и моди- 
фицировать значения переменных (наводя на них курсор мыши или используя окно 
М/асн (Слежение)}, манипулировать потоком выполнения программы (перетаскивая 
стрелку желтого цвета) или выполнять произвольный код (вводя его в окне ттеае 
(Немедленное выполнение). Кроме того, можно просматривать стек вызовов, дизас- 
семблированный машинный код, список потоков выполнения и прочую информацию. 
отмечая соответствующие пункты в меню Оберид=>\/Ипао\м$ (Отладка=Окна). За допол- 
нительной справочной информацией по отладчику обращайтесь к специально посвя- 
щенным этому ресурсам \У15иа1 Зеаато. 
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Вхождение в исходный код .МЕТ ЕгатемогкК 


Существует одно малоизвестное средство отладчика, которое в 2008 г. неожиданно 
стало весьма удобным. Если приложение обращается к коду посторонней сборки, обыч- 
но нет возможности входить в исходный код этой сборки во время отладки (поскольку 
исходный код просто отсутствует). Однако если поставщик этой сборки опубликует код 
на сервере символов (5угпЪо! зегует), среду У1зиа1 Зёалаю можно настроить так, чтобы она 
извлекала этот код на лету и отображала во время отладки. 

С января 2008 г. Мсгозой открыла общедоступный сервер символов, содержащий 
исходный код болыпинства библиотек „МЕТ Егате\могК. Теперь можно входить в ис- 
ходный код Зузсет.Мер. 4911 и других сборок ядра. Это исключительно полезно, когда 
вы сталкиваетесь с загадочной проблемой, решить которую не помогает даже Соозе. 
Сервер символов предоставляет больше информации, чем может обеспечить дизассемб- 
лирование с помощью Вейесог — вы получаете доступ к оригинальному исходному коду 
со всеми комментариями (рис. 7.7). 

Для настройки такого доступа понадобится среда \1зиа1 Зна@1о 2008 $Р1. Соответ- 
ствующие инструкции можно найти по адресу геЕегепсезойигсе. пу схкозоЕ® . сош/ 
зекхуегхзесир .азрх. 


Рогтднепйсавол.сз \ додыех НогпЕСоннонег.сз & ях! 


бесит, Рояли еписавой я тамаьсосненияо изенфагле, 500! сгеабеРесвйенеС соке, $ т. 
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Сонз 613 


Рис. 7.7. Вхождение в исходный код средства Еогтз Ашпеписавоп в Мсгозо_ АЗРМЕТ 


На заметку! В Мегозой решили предоставить возможность даже свободно загружать исходный 
код АЗРМЕТ М\УС, что позволяет его компилировать (и модифицировать) самостоятельно. 
Однако это не касается исходного кода библиотек .МЕТ Ргатемог!К — доступ к нему можно 
получить только через сервер символов Мсгозой во время отладки. Загрузить исходный код 
библиотек „МЕТ Ргатемюогк целиком и скомпилировать самостоятельно нельзя. 


Вхождение в исходный код АЗР.МЕТ МУС 


Поскольку исходный код АЗРМЕТ МУС доступен для свободной загрузки целиком, в 
решение можно включить исходный код Зузвет.Иер .Мус (как если бы он был создан 
зами). После этого во время отладки с помощью пункта меню Со 1ю ОБес!аганоп (Перейти 
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к объявлению) в \151а! За о вы сможете переходить по любой ссылке из написанного 
исходного кода к исходному коду платформы. Это может сэкономить массу времени при 
определении причин некорректной работы приложения. 

Настроить такой достун нетрудно, если помнить о нескольких возможных проблемах 
и способах их решения. После выхода в печать этой книги инструкции на этот счет мо- 
гут претерпеть изменения, поэтому ищите актуальную информацию в блоге автора по 
адресу ВЕЕр://Е1пуце1 .сом/ЧеБидМус. 


Конвейер обработки запросов 


Выше был представлен обзор проектов АЗРМЕТ МУС с точки зрения среды разра- 
ботки \15ща1 Збаа1о. Теперь давайте рассмотрим, что в действительности происходит во 
время обработки процессами МУС Егате\уогК каждого входящего запроса. 

Конвейер обработки запросов АЗРМЕТ МУС сравним с жизненным циклом стра- 
ницы в АЗР.МЕТ \еЪЕогил$ в том смысле, что он отражает внутреннюю организацию 
системы. Хорошее его понимание совершенно необходимо в ситуациях, когда применя- 
ются какие-то нестандартные подходы. В отличие от жизненного цикла традиционной 
страницы АЗР.МЕТ, конвейер МУС чрезвычайно гибок: любую его часть можно моди- 
фицировать по собственному усмотрению; можно даже вообще реорганизовать или за- 
менить компоненты. Обычно расширять или изменять этот конвейер не требуется, но 
делать это можно — именно на этом основана всесторонняя расширяемость АЗР МЕТ 
МУС. Например, при разработке приложения Зрои5${оге был реализован специальный 
фабричный интерфейс ТСопЕго11егРасбоку для создания экземпляров контроллеров 
через контейнер ТоС. 

На рис. 7.8 показано представление конвейера обработки запросов. Центральная 
вертикальная линия обозначает стандартный конвейер АЗРМЕТ МУС (для запросов. 
визуализирующих представление}, а боковые ответвления символизируют основные 
точки расптиряемости. 


На заметку! Чтобы не слишком усложнять картину, на диаграмме не показаны все события и точ- 
ки расширения. Самое важное, что не показано — фильтры, которые можно внедрять перед и 
после выполнения методов действий, а также перед и после выполнения результатов действий 
(включая У1емВези1{ $). Например, в главе применялся фильтр [АцЕВог1 те] для обеспече- 
ния безопасности и контроллера. Дополнительные сведения о том, куда должны подставляться 
фильтры, вы узнаете далее в зтой главе. 


В оставшейся части главы приводится более подробное описание конвейера обра- 
ботки запросов. Затем в главах 8, 9 и 10 каждый из основных компонентов рассматри- 
вается по очереди, давая исчерпывающее представление о средствах и возможностях 
АЗРМЕТ МУС. 


Стадия 1: сервер 1$ 


Информационные службы Интернета (6\егпеё пзЮгтаНоп Зегусез — П5$), реали- 
зующие производственный веб-сервер Мсгозой, играют центральную роль в конвейе- 
ре обработки запросов. При поступлении каждого НТТР-запроса и перед активизацией 
АЗРМЕТ драйвер устройства \Япо\гз режима ядра по имени НТТР. $У5$ анализирует за- 
прошенную комбинацию ОВГ/номер порта/ЛР-адрес, сопоставляет ее со списком прило- 
жений и передает зарегистрированному приложению (которым является либо веб-сайт 
1$, либо виртуальный каталог внутри веб-сайта ПЗ). 
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`Входящий 
запрос НТТР 


ИЗ/АЗРМЕТ 


Базовый механизм маршрутизации 
(Ог1ВоцЕ1паМоан1е) 

Обслуживается 
непосредственно 


Специальный обработчик маршрутизации 


(ТВонъеНапа1ег) Совпадающий элемент маршругизации. 


(в ВоцфеТаб1е.Воцее5} 
Специальный обработчик 
(ТНЕЕрНапа]1ек) 


Маршрутизация МУС Ргатемюие 
(МусвочкеНап Тех} 


Фабрика контроллеров 
(Реёа1ЕСопеко11екКасфоку или? 


ы сп НЫЙ ТтегЕгаскоку 
Нестандартный контроллер ециальный тсовехоз аа На 


(ТСопего3 Тег) 


Обычный контроллер Г 
(унаследованный от Сопехоз1ек) 


Ваш метод действия 


Запись непосредственно 
вНТТР-ответ 


Возврат результата действия 
(АсезопВези1 Е} 


к. 


Выполнение АсЕ+опВезо 1+ 


( )) Механизм представлений 


Ваше представление Ме Рогт 


Визуализация представления МеЕоит 


Специальный 
механизм представлений 
(ТУЗемЕпоз пе) 


Рис. 7.8. Конвейер обработки запросов АЗРМЕТ МУС 
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Поскольку приложения АЗРМЕТ МУС построены на основе платформы АЗРМЕТ, она 
должна быть включена для этого пула приложений ПЗ (каждое приложение П$ назна- 
чается в определенный пул). Включать АЗРМЕТ можно в одном из двух управляемых 
режимах конвейера. 


® В режиме 1ЗАЫ, который также называется классическим режимом, АЗРМЕТ вы- 
зывается через расптирение (азрпее 1зар1.911) ?. ассоциированное с определен- 
ными расигирениями имен файлов в ОН. (например, .азрх, .азНх, .шус). В П$ 6 
можно настроить отображение по шаблону, так что азрпе®е 1зар1 .911 будет ото- 
бражать все запросы, независимо от расширения имени файла в ОВ1.. Более под- 
робные сведения о развертывании приложений МУС ЕгатехмогК на сервере ПЗ 6, 
включая настройку отображения по шаблону, можно найти в главе 14. 


® В интегрированном режиме (поддерживаемом только в ПЗ 7+), МЕТ является ес- 
тественной частью конвейера обработки запросов ПЗ, так что никаких расшире- 
ний [ЗАР!, ассоциированных с определенным расширением имени файла в ОВ. 
не понадобится. Это облегчает использование конфигураций маршрутизации с 
чистыми ОЕ, (те. без расптирений имен файлов). 


В любом случае, как только АЗРМЕТ получает входящий запрос, каждый зарегист- 
рированный модуль НТТР уведомляется о начале нового запроса. (Модуль НТТР — это 
класс .МЕТ, реализующий интерфейс ТНЕЕрМодо1е, который можно “подключить” к кон- 
вейеру обработки запросов АЗРМЕТ.) 

Одним из важных модулей НТТР, регистрируемых по умолчанию в любом приложе- 
нии АЗРМЕТ МУС, является Ог1ВопЕ1п9Моао1е. Этот модуль представляет собой на- 
чало базовой системы маршрутизации, которая рассматривается ниже. Наличие узла 
<БЕЕрМоади1ез> в файле мер .сопЕ1а говорит о том, что этот модуль зарегистрирован 
для ПЗ 6: 


<зузсет.мер> 
<БЕЕРМо@аи1е5> 
<ааЯ пате="Охг1Коц1пдМодо1е" фуре="Зузфет.Меь .ВКоце1та.Цк1Восе1п9Моди1е, ..." /> 
</ВЕЕРМоди1е5> 

</зузеем.мер> 


Если вы имеете дело с ПЗ 7, откройте его графический интерфейс Модце$ (Модули). Для 
этого дважды щелкните на элементе Администрирование панели управления, затем в от- 
крывшемся окне дважды щелкните на элементе Диспетчер служб И5, в дереве слева выбе- 
рите свой веб-сайт и затем дважды щелкните на значке Модули. В открывшемся графиче- 
ском интерфейсе Модули можно отредактировать узел <зузеет.меббегуег>/<поди1ез> 
из мер.сопЕ1а (рис. 7.9). 


Стадия 2: базовая маршрутизация 


Когда модуль Ох1Воце1п9Моди1е вовлекается в обработку запроса, запускается сис- 
тема маршрутизации Зузбет. Иер .Воч{1п9. Задача маршрутизации состоит в распо- 
знавании и разборе произвольных шаблонов входящих ОКТ, с установкой структуры 
данных контекста запроса, которой будут пользоваться последующие компоненты (на- 
пример, в АЗРМЕТ МУС эта структура служит для передачи управления соответствую- 
щему классу контроллера МУС и для передачи параметров методам действий). 


? АР-интерфейс служб Интернета (Ниегпе! Зеглсез АР! — ТЗАР — это старая система под- 
ключаемых модулей П$. Расширения [АР можно создавать только в неуправляемом коде 
(Бапример, С/С++). 
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Рис. 7.9. Редактирование модуля Охт1ВочЕ1паМоди1е 
в графическом интерфейсе МодЦез$ 


На рис. 7.8 видно, что во время базовой маршрутизации сначала производится про- 
верка, соответствует ли входящий ОВГ какому-то файлу на диске. Если да, то маршру- 
тизация завершается, и дальнейшая обработка этого запроса поручается серверу ПЗ. 
Для статических файлов (например, .91Е, .)ред, .рпд, .с$3 или .)5) это означает, что 
сервер ПЗ обработает их естественным образом (потому что они существуют на диске), 
что очень зффективно. Аналогично, это означает, что традиционные страницы .азрх 
АЗРМЕТ \еЕогилз также будут обработаны обычным образом (поскольку они также 
присутствуют на диске). 

Однако если входящий ОВ! не соответствует никакому файлу на диске (например, 
запросы к контроллерам МУС, представляющим собой типы „МЕТ, а не файлы на диске), 
то для выяснения способа обработки входящего ОБТ, на стадии базовой маршрутизации 
анализируется активная конфигурация. 


Конфигурация маршрутизации 


Конфигурация маршрутизации содержится в статической коллекции по имени 
Зузеен.иер.ВоцЕ1па .ВопееТаю1е .Воикез. Каждый ее элемент представляет собой от- 
дельный шаблон ОГ, с необязательными заполнителями для параметров (например, 
/Ъ1о9/ {уеаг} / {епеку}) и ограничениями, которые лимитируют диапазон допустимых 
значений каждого параметра. Каждый элемент также специфицирует обработчик мар- 
шрута — объект, реализующий ТВопееНапа1ех, — который получает и обрабатывает 
запрос. Обычно коллекция ВоиееТаЬ1е .Воибез заполняется добавлением кода к методу 
по имени Вед1зтетгВоцеез () в файле С1оБа1 .азах.сз. 

Чтобы сопоставить входящие запросы с определенными злементами ВонхетаБ1е. 
ЗоцЕез, система базовой маршрутизации просто начинает с начала коллекции 
ЗоифеТа1е.Воцеез и просматривает список вниз, выбирая первый элемент, кото- 
рый соответствует входящему запросу. Найдя такой элемент, маршрутизация пере- 
дает управление объекту-обработчику, указанному для зтого элемента, передавая 
ему структуру данных “контекста запроса”, которая описывает выбранный элемент 
зоцЕеТаЬ1е.ВКоцсез, и все значения параметров, переданные в ОБТ. Здесь вступает в 
действие МУС Егате\огК, что мы и рассмотрим далее. 


Более детальные сведения о системе маршрутизации предлагаются в главе 8. 
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Стадия 3: контроллеры и действия 


Итак, система маршрутизации выбрала определенный элемент Воц$еТар1е.Воцфез 
и разобрала все параметры маршрутизации из ОВГ. Она упаковала эту информацию в 
структуру. именуемую контекстом запроса. Когда же на сцену выходят контроллеры 
и действия? 


Поиск и вызов контроллеров 


Для приложений АЗРМЕТ` МУС почти все элементы ВоцееТаЪ1е .ВоцЕез специфици- 
руют один определенный обработчик маршрута — МусВонееНапаТег. Это встроенный 
в АЗРМЕТ МУС стандартный обработчик маршрутов, служащий мостом между основ- 
ной маршрутизацией и собственно МУС Егате\хогК. Обработчику МусВоцееНапа1ехк 
известно, как получить данные контекста запроса и вызвать соответствующий класс 
контроллера. 

Как показано на рис. 7.8, это делается с помощью объекта фабрики контроллеров. По 
умолчанию используется встроенная фабрика по имени РеЁац1Соп&го11ехРасфоху, 
которая при определении корректного класса контроллера для каждого конкретно- 
го запроса следует определенным соглаптениям об именовании и о пространствах 
имен. Однако если вы замените встроенный РеЕаи1ЕСопЕго11етхЕас®оку каким-то 
другим объектом, реализующим интерфейс ГСопЕхо11егЕас®огу, или подклассом 
Регаи1ЕСопего11егЕас®огу. то сможете изменить эту логику. Такой подход уже при- 
менялся в главе 4 при включении контейнера ТоС в конвейер обработки запросов. 


Что должны делать контроллеры 


Минимальное требование к классу контроллера состоит в том, что он должен реали- 
зовать интерфейс ТСопЕго1 Тег: 


руб11с 1птекЕасе ТСопеко11ег 


{ 
х01а Ехесите (ВедиезСопеехЕ гечиезЕСопфех®); 


} 


Как видите, интерфейс довольно прост. На самом деле он не специфицирует ниче- 
го помимо того, что контроллер должен что-то сделать (т.е. реализовать Ехесиее ()). 
Обратите внимание, что параметр гедаезСопеехе предоставляет все данные контек- 
ста запроса, сконструированного системой маршрутизации, в том числе параметры, 
которые извлечены из ОВГ. Кроме того, гедиезСопфехе предоставляет доступ к объ- 
ектам Кедаез{ и Везропзе. 


Что обычно делают контроллеры 


Чаще всего интерфейс ТСопего11ех не реализуется непосредственно. Вместо этого 
создаваемые классы контроллеров наследуются от бузеею.Иер.Мус .Сопего11ек. Это 
встроенный стандартный класс контроллера МУС ЕгатехогК. который добавляет до- 
полнительную инфраструктуру для обработки запросов. Что более важно, он вводит в 
систему методы действий. Это значит, что каждый из общедоступных методов класса 
контроллера может быть вызван через некоторый ОВ! (такие общедоступные методы 
называются методами действий) и это значит, что реализовывать Ехесиее (} вручную 
не понадобится. 

Хотя методы действий могут посылать вывод непосредственно в НТТР-ответ, посту- 
пать так не рекомендуется. Из соображений тестируемости и повторного использования 
кода (о котором речь пойдет ниже) для методов действий лучше возвращать результат 
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действия (объект, унаследованный от Асе1опВези1), который описывает желаемый 
вывод. Например, если необходимо визуализировать представление, вернуть следует 
УтемВези1%. Каркас МУС затем позаботится о выполнении результата в соответствую- 
щий момент в конвейере обработки запросов. 

Существует также очень гибкая система фильтров. Это атрибуты „МЕТ (например, 
[АчЕВог17е]), которыми можно “пометить” класс контроллера или метод действия, 
внедряя подобным образом дополнительную логику, которая будет выполняться перед 
или после методов действий либо перед или после выполнения результатов действий. 
Существует даже встроенная поддержка специальных типов фильтров (фильтров ис- 
ключений и фильтров авторизации), активизируемых в определенные моменты време- 
ни. Фильгры могут появляться в настолько разных местах, что все их даже не удалось 
показать на рис. 7.8. 

Контроллеры и действия (а также связанные с ними средства) образуют несущую 
конструкцию МУС Егате\уогК. Дополнительные сведения о них вы узнаете в главе 9. 


Стадия 4: результаты действий и представления 


К настоящему времени уже много чего произошло. Давайте подытожим. 


® Система маршрутизации сопоставила входящий ОНТ, со своей конфигурацией и 
подготовила структуру данных — контекст запроса. Соответствующий элемент 
ВоифеТаБ1е .Вос®е выбрал Мускоц$еНап1ех для обработки запроса. 


® Обработчик МусвоцееНапЯ1ет использовал данные контекста запроса с фабри- 
кой контроллеров для выбора и вызова класса контроллера. 


® Класс контроллера вызвал один из своих методов действий. 
® Метод действия вернул объект АсЕ1опВези1е. 


В этой точке МУС ЕгатехогК запросит выполнение объекта Асе1опВези1 и на этом 
все. Асс1опВези1 выполнит то, что должен делать тип АсЕ1опВези1е (те. вернет стро- 
ку или данные 4ЗОМ в браузер, произведет перенаправление НТТР, потребует аутенти- 
фикации и тп.). В главе 9 вы узнаете о встроенных типах Асф1опВези1+, а также о том, 
как создавать собственные специальные типы. 


Визуализация представления 


Особое внимание стоит уделить одному подклассу АсЕ1опВези1Е — У1емВезо1. 
Он занимается поиском и визуализацией определенного шаблона представления, по- 
путно передавая структуру данных У1емрафа, которая сконструирована методом дей- 
ствия. Это делается вызовом механизма представлений (класса .МЕТ, реализующего 
ТУтемЕра1пте), назначенного контроллером. 

Механизм представлений по умолчанию называется ИерЕоги\У1емЕпа1пе. Его шаб- 
лоны представлений — это страницы АЗРХ \МеЬЕогил$ (те. серверные страницы, ис- 
пользуемые АЗРМЕТ \еБЕогил$). Страницы \еБЕогп1$ имеют собственный конвейер об- 
работки, который начинает с компиляции “на лету” АЗРХ/АЗСХ и проходит через ряд 
событий, известных под общим названием жизненный цикл страницы. В отличие от 
традиционных \ЪЕогта$, эти страницы должны быть предельно простыми, потому что 
при четком разделении ответственности МУС шаблоны представлений не должны де- 
лать ничего кроме генерации НТМТ-разметки. Это означает, что детально разбираться 
в жизненном цикле страниц \\е Еогпл$ не нужно. Четкое разделение ответственности 
способствует простоте и сопровождаемости кода. 
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На заметку! Чтобы разработчики МУС не включали в представления АЗРХ обработчики событий 
в стиле \\еБРогтз, эти представления обычно вообще не имеют соответствующих классов от- 
деленного кода. Тем не менее, создавать такие классы в файле отделенного кода можно, соз- 
дав в Мвиа! Зи ®ю обычную форму \еЪ Рогт в соответствующем месте представления и затем 
унаследовав этот класс отделенного кода не от ЗузЕет.Меь.ОТ.Расе, а от У1еиРаде (или 
от У1емРаде<Т> для некоторого типа модели Т}. Однако заниматься трюкачеством подобного 
рода не рекомендуется. 


Разумеется, можно реализовать собственный тип Т\/1еиЕро1пе, полностью заменив 
механизм представления \МеЬРогиз$. В главе 10 будет дана исчерпывающая информация 
о представлениях, в частности, о механизме представлений \еБЕогил$, а также о неко- 
торых альгернативных и специальных механизмах представлений. 


Резюме 


В этой главе обзор приложений АЗРМЕТ МУС был представлен с двух точек зрения. 


® С точки зрения структуры проекта было показано, как работают шаблоны про- 
ектов МУС \У15иа1 Эбаа1ю, и каким образом файлы кода организованы по умолча- 
нию. Вы узнали о том, какие файлы, папки и соглашения об именовании являются 
рекомендованными, а какие — обязательными для данного каркаса. Вы также оз- 
накомились с особенностями отладки приложений АЗРМЕТ МУС в \Изиа] Задлю. 


® С точки зрения исполняющей системы было показано, как АЗРМЕТ МУС обраба- 
тывает входящие НТТР-запросы. Был описан весь конвейер, начиная с определе- 
ния соответствия маршрута, активизации контроллеров и действий, и заканчивая 
шаблонами представлений, которые посылают готовую НТМГ-разметку обратно 
в браузер. (Это лишь поведение по умолчанию; не существует пределов гибкости 
в реорганизации конвейера, добавлении, изменении или удалении компонентов. 
Платформа МУС ЕгатемогК предлагает разработчикам полный контроль над ка- 
ждым своим действием.) 


Благодаря следующим трем главам ваши пока поверхностные знания превратятся 
в глубокое и всестороннее понимание каждой составной части АЗРМЕТ МУС. Глава 8 
посвящена маршрутизации. В главе 9 описаны контроллеры и действия, а в главе 10 — 
представления. Вы узнаете обо всех доступных вариантах и о том, как наилучшим спо- 
собом использовать каждое доступное средство. 


ГЛАВА 8 


ОБЕ и маршрутизация 


основе марптрутизации, реализованной в АЗРМЕТ \еЪЕогп1$ и многих других 

платформах веб-приложений, лежит принцип прямого соответствия ОВТ, файлам 
на жестком диске сервера. Сервер выполняет и обслуживает страницу или файл, соот- 
ветствующий входящему ОВТ. В табл. 8.1 приведен пример. 


Таблица 8.1. Традиционное соответствие УВЕ файлам на диске 


Входящий ЧВЕ Может соответствовать 

ВЕЕр: //туз1 Ее .сот/ЧаеЕац1+ .азрх е: \иебкоо*\ЯеЕаи1%.азрх 
Бер: //музлее.соп/ади1т/10940.азрх е: \меБхоо®\ади1и\1о91т.азрх 
БЕЕр: //тмузтсе .сот/агЕ1с1ез/Аппиа1Веулем Файл не найден! 


Послать сообщение об ошибке 404. 


Такое четкое соответствие легко понять, но в то же время оно сильно ограничивает, 
Почему имена файлов и структура каталогов проекта должны быть представлены на 
всеобщее обозрение? Разве это не детали внутренней реализации? И что делать с этими 
неуклюжими расширениями .азрх? Понятно, что и для конечного пользователя они не 
слишком удобны. 

Традиционно на платформе АЗРМЕТ разработчик вынужден был трактовать ОВГ. как 
черный ящик”, не уделяя никакого внимания структуре ОЕ! или поисковой оптимиза- 
ции (зеагсВ епбше орйпихаНоп — ЗЕО). Распространенные обходные пути, наподобие 
специальных обработчиков ошибки 404 и ЗАРГ-фильтров перезаписи ОВ, могут ока- 
заться трудными в настройке и привносят с собой собственные проблемы. 


Возвращение программисту 
контроля над программой 


Платформа АЗРМЕТ МУС отличается тем, что ОБТ, болыше не рассматриваются как 
прямые соответствия файлам на веб-сервере. Фактически это даже не имело бы смыс- 
ла. так как запросы АЗРМЕТ МУС обрабатываются классами контроллеров (скомпили- 
рованными в сборки .МЕТ), то нет никакого соответствия между конкретными файлами 
и входящими ОВТ.. 

Программисты получают полный контроль над схемой ОВГ. те. набором приемле- 
мых ОВ. и их отображением на контроллеры и действия. Эта схема не ограничена ка- 
=им-то предопределенным шаблоном и не должна включать расширений имен файлов 
или имен классов и файлов кода. Пример показан в табл. 8.2. 
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Таблица 8.2. Отображение системой маршрутизации произвольных УВЕ 
на контроллеры и действия 
——— 


Входящий ЦВЕ Может соответствовать 

Веер: //туз1ее .соп/рвото$ { сопеко] Лек = "ба Леку", 
асЕ1оп = “Р1зр]ау" } 

БЕЕр:/ /туз1е.соп/адт1п/ 1091 { сореко]Тек = "Ацев", 
асе1оп = "Год1п” } 

ВЕЕр://тузуее .сош/ак1с1ез/Аппоа1Веу1ем { сопехо]Тегк = "Аке1с1ез", 
асетоп = “Улем", 
сопсепеТеетМате = 


"Аппоа1Веулем" } 
—___ 
Все это управляется системой маршрутизации платформы. После соответствующе- 
го конфигурирования система маршрутизации выполняет две главных функции. 


1. Отображает каждый входящий ОВ! на соответствующий класс — обработчик 
запросов. 


2. Конструирует исходящие ОВТ,, направляющие в другие части приложения. 


Базовая система маршрутизации АЗРМЕТ полностью независима от остальной час- 
ти платформы МУС. Именно поэтому она находится в отдельной сборке (Зузеет.Меь. 
Вопе1п9. 911) и пространстве имен. Ей ничего не известно о концепциях контроллеров 
и действий — эти имена параметров являются лишь произвольными строками для сис- 
темы маршрутизации, и они трактуются так же, как любые другие имена параметров, 
которые можно выбрать. 


На заметку! Библиотека бузсет.меь .ВоцЕАпа. 911 изначально поставлялась в составе МЕТ 3.5 
$Р1 задолго до появления АЗРМЕТ М\С, поэтому она может использоваться приложениями 
АЗРМЕТ Бупат ОБайа. Весьма вероятно, что будущая версия АЗРМЕТ 4.0 ( которая будет вклю- 
чена в \Мзиа} Зв ю 2010) сможет также применять систему маршрутизации, предоставляя раз- 
работчикам \МебРогтз удобный способ организации чистых ИВЕ. В этой главе основное вни- 
мание сосредоточено на маршрутизации в рамках АЗРМЕТ МУС, но большая часть сведений 
также касается маршрутизации и на других платформах. 


В главе 7 вы узнали, что маршрутизация запускается на очень ранней стадии кон- 
вейера обработки запроса и является результатом регистрации Ох1Воц1п9Модо1е в 
качестве одного из НТТР-модулей приложения. В этой главе вы узнаете, как конфигу- 
рировать, использовать и тестировать базовую систему маршрутизации. 


Настройка маршрутов 


Для того чтобы посмотреть, как маршрутизируются запросы, создайте новый пустой 
проект АЗЕМЕТ МУС и загляните в файл С10Ъа1.азах.сз: 


рур14с с1азз МусАрр11са оп : ЗузЕет. Мер. НеЕрАрр]1саЕ1оп 
{ 
рготесееЯ уо1а Арр11сае1оп 5%ахке() 
{ 
Вед1зтегВопеез (Коцеетаф1е.Воиеез} ; 
} 
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руБ11с збаЕ1с уо1а Вед1зфетКойцфез (ВоофеСо11есЕе1от коп®ез) 

{ 
топеез .ТапогеВоцее (" { гезоигсе} .аха/ {*рабВТпРо}"); // Это объясняется позже 
гоцее$ .МарВоце ( 


"РеЁа114", // Имя маршрута 
" { сопЕхо11ек}/ {асЕ1оп}/{1а}", // ОВЬ с параметрами 
рем { сопего1Тег = "Ноше", ас®Е1оп = "Тпдех", 1а = "" } // Значения 


// параметров по умолчанию 


); 
} 


Когда приложение запускается впервые (те. выполняется Арр11саЕ1оп_беаке ()), 
этот код заполняет глобальный статический объект ВосЕеСо11есе1оп по имени 
ВоисеТаь1е .Воцеез. Именно в этой коллекции хранится конфигурация маршрутиза- 
ции приложения. Наиболее важный код выделен полужирным: МарВосее () добавляет 
элемент к конфигурации маршрутизации. Чтобы понять, что это значит, вы должны 
знать, что этот вызов МарКопее () — просто сжатая альтернатива следующему коду: 

Копее шуВочее = пем Воже (" {сопего11ек} /{асЕ1оп}/{19}", пем 

МусКоотеНапаТег ()) 

{ 


РеРаз1е$ = пем Кочтеуа1аер1сЕ1опагу( пем { 
сопЕго11ег = “"Нопе", асбтоп = "Траех", 14а = "" 
}) 
}; 
гоисез.Ада ("регаз1®", шуКоцее); 


Каждый объект Вооее определяет шаблон ОВГ. и описывает, как обработать запросы 
для этого ОКУ. В табл. 8.3 показано, что означает этот конкретный элемент 


Таблица 8.3. Отображение элементов маршрута по умолчанию на входящие УВЕ 


В Отображается на 

/ { сопекго11ег = "Ноше", асЕ1фоп = "Траех", 1а="" } 
/Еогим { сопеко11ек = "Рогийш", асе1оп = "Тпаех", 19="" } 
/Еогом/ ЗВомТор1св { сопЕко11ек = "Гокош", асё1ор = "ЗромТортс8", 1а = "" } 
/Еотат/ 5ВоиТор1с8/75 { сорго ек = "Рога", асё1ор = "ЗВомТорлсз", 1а = "75" } 


В каждом элементе ВосееТаю1е можно настраивать пять свойств. Эти свойства оп- 
ределяют, совпадает ли он с заданным ОВ, и указывают действия. производимые в от- 
ношении запроса в случае совпадения (см. табл. 8.4). 


Механизм маршрутизации 


Механизм маршрутизации запускается в начале конвейера обработки запросов. Его 
работа состоит в том. чтобы взять входящий ОН! и использовать его для получения 
объекта ТНЕЕрНапа1ек, который обработает запрос. 

Многих новичков в МУС Егатехогк маршрутизация приводит в замешательство. 
Она не имеет аналогов на традиционной платформе АЗРМЕЛ, и ее очень легко сконфи- 
гурировать неправильно. Как следует разобравитись в ее внутреннем устройстве, вы из- 
бежите этих трудностей, а также сможете значительно расптирить механизм, добавляя 
необходимое поведение во всем приложении. 
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Основные элементы: КоиЁеВазе, КоиЁе и КоиЁеСо11есЕ1оп 


Конфигурация маршрутизации построена с помощью трех основных элементов. 


® ВоптеВазе — абстрактный базовый класс для элемента маритрутизации. Унаследо- 
вав собственный специальный тип от этого класса (в конце главы будет приведен 
пример), можно реализовать необычное поведение марирутизации, но пока о нем 
можно забыть. 


® Ропте — стандартный, часто используемый подкласс ВоиееВазе, который вво- 
дит понятия шаблонов ОЕ, настроек по умолчанию и ограничений. Это то, что 
встречается в болыпинстве примеров. 


® ВоцееСо11есЕ1оп — полная конфигурация маршрутизации. Представляет собой 
упорядоченный список объектов-наследников ВоофеВазе (например, объектов 
Воцее). 


ВочееТаь1е.ВБоиеез! — это специальный статический экземпляр ВопееСо1ЛесеТоп. 
Он представляет текущую, активную конфигурацию маршрутизации приложения. 
Обычно он заполняется только однажды, при запуске приложения в первый раз, в ме- 
тоде Арр11са®1оп беагё() из С1офа1.азах.сз. Это статический объект, поэтому он 
существует на протяжении всего времени жизни приложения, и не пересоздается по 
каждому запросу. 

Обычно код конфигурации не встраивается непосредственно в метод Арр11сае1оп _ 
Зеаге (), а выносится в метод по имени Вед1зкетВоиеез (). Это облегчает доступ к 
конфигурации из автоматизированных тестов (как было показано при тестировании 
маршрутов в главе 5 и вновь будет показано далее в этой главе). 


Место маршрутизации в конвейере обработки запросов 


При запросе ОВ! система вызывает каждый из зарегистрированных для приложе- 
ния экземпляров ТНЕЕрМода1е. Один из них, Охг1КопЕ1п9Модо1е (его можно увидеть в 
файле меЬ. сопЕ1 9), выполняет три функции. 


1. Находит первый объект ВоифеВазе в КоцееТаБ1е .Воиеез, который соответствует 
данному запросу. Стандартные элементы Вобее совпадают в случае удовлетворе- 
ния следующих трех условий. 


е Запрашиваемый ОЕГ, соответствует шаблону ЧЕТ. данного Воцее. 


®е Все параметры, заданные в фигурных скобках, присутствуют в запрошенном 
ВТ или в коллекции РеЁао1%5 (те. все параметры учтены). 


® Удовлетворено каждое условие из коллекции СопзЕгалтпез. 


е ПОг1Вопе1п9Моаы1е начинает с начала коллекции ВоотеТаЬ1е .Воп&ез и про- 
сматривает все элементы по порядку. Просмотр прекращается при нахождении 
первого соответствия, поэтому важно, чтобы наиболее специфичные элементы 
маршрута располагались в начале. 


2. Запрашивает у соответствующего объекта ВоцееВазе структуре Вооферака, кото- 
рая специфицирует, каким образом должен быть обработан запрос. Воскерафа — 
простая структура данных с четырьмя свойствами. 


е Воиге. Ссылка на выбранный элемент маршрута (типа ВоофеВазе}. 


1 Его полное имя выглядит как бузёей.Мер.Воп&1п9 .ВочбеТаю1е .Воифез. 
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® Росбенап Тек. Объект, реализующий интерфейс ТВоофеНапо] ет, который обработа- 
ет запрос (в приложениях АЗРМЕТ МУС это обычно экземпляр МусвонЕенаро1 ег”). 


® \Уа1щез. Словарь, хранящий имена параметров в фигурных скобках и значения, 
извлеченные из запроса, а также значения по умолчанию для всех параметров 
в фигурных скобках, которые не были указаны в ОВ. 


® ПагаТокепз. Словарь, хранящий все дополнительные настройки конфигура- 
ции, поставляемые элементом маршрутизации (более подробно рассматрива- 
ются в следующей главе}. 


3. Вызывает КоцкеНап Лек из Воикерака. Передает Воикенапа1ег всю доступную 
информацию о текущем запросе в параметре по имени гедиез+Сореех+. Сюда 
входят структуры Воиферака и объект НЕЕрСопбехеВазе, который специфицирует 
всю контекстную информацию. включая НТТР-заголовки, соок!е-наборы, состоя- 
ние аутентификации, данные строки запроса и отправленные данные формы. 


Значение порядка следования элементов маршрута 


“Золотое правило” маршрутизации формулируется следующим образом: поме- 
щайте более специфичные элементы маршрута перед менее специфичными. Да, 
ВоцееСо11есе1оп представляет собой упорядоченный список, и порядок добавления в 
него элементов очень важен для процесса сопоставления маршрута. Система не пытает- 
ся найти “наиболее специфичное” соответствие для входящего ОБТ; используемый алго- 
ритм состоит в том, что просмотр начинается с начала таблицы маршрутов, по очереди 
проверяется каждый элемент, и просмотр останавливается при нахождении первого сов- 
падения. Например, никогда не конфигурируйте марптруты так, как показано ниже: 


гопЕез .МарБКооее ( 


"БеЕау1", // Имя маршрута 
" { сопЕго11ег} / {асё1оп}/{1а}", // ОБЬ с параметрами 
пем { сопеко11ег = "Ноше", асё1ор = "Тпдех", 19 ="" } // Значения 


// параметров по умолчанию 
); 
гоцеез .МарВоите ( 


"Зрес1а1°", // Имя маршрута 
"Ра11у5рес1а1з/ {Чабе}", // ОВЬ с параметрами 
пем { сопего11ег = "Сафа1о9", асЁ1оп = "5Ноибрес1а1з" } // Значения 


// параметров по умолчанию 
); 
Причина в том, что /Ра11у5брес1а1з/МаксН-31 будет соответствовать первому эле- 
менту. а это породит значения Воцкерафа, перечисленные в табл. 8.5. 


Таблица 8.5. Результаты неправильной интерпретации запроса 
/Раз1убрес1а1з/Махсь-31 для предыдущей конфигурации маршрутизации 


Ключ Боцферака Значение ВоцЕерафа 
СопЕго Лек Ра11убрес1а13 
асетоп Магсв-31 

та Пустая строка 


э—<— дд 


е Обработчику МусКоцееНапа1ет известно, как находить и вызывать классы контроллеров 
(на самом деле он делегирует выполнение этой задачи обработчику НТТР под названием 
мусНапа1ег, который обращается к зарегистрированной фабрике контроллеров за создани- 
ем определенного контроллера по имени). Фабрики контроллеров более подробно рассмат- 
риваются в следующей главе. 
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Очевидно, что это не то, что требуется. Дело даже не дойдет до Саба1очСопего11ег, 
потому что начальный элемент уже перехватывает нтирокий диапазон ОНТ.. Решение со- 
стоит в изменении порядка следования этих элементов. Па11убрес1а1з/ {асе} более 
специфичен, чем {сопеёго11ег} /{асе1оп}/ {1а}, поэтому он должен располагаться в 
списке выше. 


Добавление элемента маршрута 


Маршрут по умолчанию (соответствующий {сопего11ек}/ {асЕ1оп}/{149}) имеет 
настолько общий характер, что вокруг него можно построить целое приложение, без 
необходимости иметь другие элементы конфигурации. Однако если вы захотите обра- 
батывать ОВГ, которые не имеют никакого отношения к контроллерам или действиям, 
то вам понадобятся другие элементы конфигурации. 

Начнем с простого примера. Предположим, что ЧЕТ. вида /Сафа1од должен направ- 
лять к списку товаров, и существует класс контроллера по имени Ргодас& зСопего11ек. 
включающий метод 1151 (). В этом случае потребуется добавить следующий маршрут: 


гопез.АаЯ (пем Копбе ("Сафа1од9", пем МусВоцееНапд1ег () } 
{ 


Рерас1ез = пеи Воибеуа1ще01сЕ1опагу ( 
пем { сопего11ек = "Ргодосез", асётоп = "1136" } 
) 
}); 


Этот элемент будет соответствовать ЧЕ. /СаЕа1од или /Сака1оч?зоте=ааегузЕтг1пд, 
но не /Сафа1оч/АпуЕН1пде1зе. Чтобы понять причины, давайте рассмотрим, какие 
части ОБТ, важны для элемента Воп*е. 


Шаблоны ЦРЕ, соответствующие путевой части ИВЕ 


Когда объект Кофе решает, соответствует ли он определенному входящему ОБТ, 
он учитывает только путевую часть входящего ЧВГ. Это значит, что ни доменное имя 
(также называемое хостом), ни любые значения строки запроса не учитываются. На 
рис. 8.1 показана путевая часть адреса ОБТ,З. 


ВЕЕр: //мим.ехапшр1е. соп/зоме/их1?а6с=ЧеЕ&911=7)К1 


Схема Хост Путь Строка запроса 


Рис. 8.1. Идентификация путевой части ЦВЕ. 


Продолжая предыдущий пример, отметим, что шаблон ОВЕ "Сафа1од" бу- 
дет соответствовать и Веер: / /ехапр1е .соп/Сафа1о9, и НеЕрз: //а.Ъ6.с.а:1234/ 
Саса1од?апегу=зЕ гта. 

При развертывании приложения в виртуальном каталоге шаблоны ПОЕТ, рассматри- 
ваются как действующие относительно корня виртуального каталога. Например. если 
приложение развертывается в виртуальном каталоге по имени у1г%О1г, тот же шаб- 
лон ОКТ. "Сафа1од" будет соответствовать НЕр: //ехашр1е .сот/у1кЕ01к/Сафа1о09. 
Разумеется, он уже не будет соответствовать НЕЕр://ехатр1е .соп/Сафа1од, потому 
что сервер П$ не выдаст приложению запрос на обработку этого (В. 


3 Обычно при запросе Ведиез® .Ра®п среда АЗРМЕТ возвращает ОНТ, с ведущим слэшем (на- 
пример, /Сафа10ч). Для шаблонов маршрутизации ОНТ. наличие ведущего слэша подразу- 
мевается (другими словами, не помещайте ведущий слэш в шаблоны маршрутизации ОВ1., 
а просто пишите, например, Саба1оч}. 
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Словарь Коитеуа1иер1сЕ1опагку 


Обратите внимание, что свойством РеЁал14$ в Воиее является ВоцееУа мер 1се1опаку. 
С ним связан гибкий АРГ-интерфейс, позволяющий заполнять свойство разнообраз- 
ными способами, в зависимости от предпочтений. В предыдущем коде использовался 
анонимный тип С# 3.0. Объект ВочкеУа1иер1се1опагу извлекает свой список свойств 
(в данном случае — сопего11ег и ас®1оп)} во время выполнения, а это дает возмож- 
ность предоставить произвольный список пар “имя/значение”. В резульгате получается 
весьма аккуратный синтаксис. 

Альтернативный способ заполнения Воцееуа1аер1с®1опаку состоит в передаче 
Тр1сЕ1топаку<зЕт1та, оБ)есь> в качестве параметра конструктора или применении 
средства инициализатора коллекции С# 3.0: 


гоисез.Ааа (пеи Воц(е ("СафаТоч", пем МусвВоч$еНапоа1екг ()) 
{ 
РеЁаз1+$ = пеми КопееУалер1сЕ1опаку 


{ 
{ "сопехо11ех", "Ркоаасез" }, 
{ "асефоп", "Таз" } 

} 

}); 

В любом случае ВооееУа1иер1сЕ1опагу — это просто словарь, потому он не особо 
безопасен в отношении типов и не поддерживается средством П\ёеШ$Зепзе. Это значит, 
что при наборе имен свойств вполне возможны опечатки (скажем, сопкко]1ет вместо 
сопего11ет}, которые останутся незамеченными вплоть до времени выполнения. 


Сокращение кода с помощью МарКоиЕе () 


В АЗРМЕТ МУС к классу ВоокеСо11есе1оп добавлен расширяющий метод по имени 
МарВотее (), который предоставляет альгернативный синтаксис для добавления эле- 
ментов маршрута. Возможно, он покажется вам более удобным. С его помощью тот же 
элемент маршрута можно выразить следующим образом: 


гоибез .МарВойее ("Рир11сРкоаисе$11$%", "Саба1од", 
пем { сопбго ег = "Ргодосез", асе1фой = "1136" }); 


В этом случае РоБ11сРгоЯисеТ13Е — имя элемента маршрута. Это просто произ- 
вольная уникальная строка. К, тому же она необязательна: вы не обязаны именовать 
элементы маршрута (при вызове МарВочее () можно передать по11 в качестве парамет- 
ра папе). Однако назначение имен определенным элементам маршрута обеспечивает 
другой способ сослаться на них во время тестирования или генерации исходящих ОВГ. 
По ряду причин, которые объясняются позже в этой главе, имена маршрутам предпоч- 
тительнее не назначать. 


На заметку! Назначать имена элементам маршрута можно также при вызове голфез .АаЧа () , ис- 
пользуя для этого перегрузку метода, которая принимает параметр папе. 


Использование параметров 


Ранее уже несколько раз было показано, что параметры могут передаваться в фигур- 
ных скобках. Давайте добавим параметр со1ог (цвет) к маритруту: 


гоцтез.АЯЯ (рем ВКоцсе ("Сафа1о9/{со{фог}", пем МусВоитеНапоТек ()) 


{ 
реграо1%$ = пем Волке\уа] аер1сЕ1орваху ( 
пеи { сопего11ек = "Ркодосез", асЕТоп = "ТЁ1 6" } 


}); 
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Это эквивалентно следующему коду: 


гоцбез .МарКоцее (пи11, "Сафа1о9/ {со1ог}", 
рем { сорЕго11ег = "Ргкодосе8", асёфоп = "1150" }); 


Теперь маршрут будет соответствовать таким ОВГ, как /Сата1од/уе11ои или 

Сафа1о9/1234, и система маршрутизации добавит соответствующую пару “имя/значе- 

ние” в объект Воскерата запроса. Так, например, по запросу /Сафа1о9/уе11ои элемент 
зоабераба.Уа1щез ["со1ог"] получит значение уе11о\. 


Совет. Поскольку в объектах ВоиЕе фигурные скобки (т.е. { и }) служат разделителями парамет- 
ров, их нельзя использовать в качестве нормальных символов в шаблонах ЦВЕ. Если это все- 
таки необходимо, потребуется записать { { и } }, т.е. двойные фигурные скобки, которые будут 
интерпретироваться как литерал одиночной фигурной скобки. Хотя если подумать, то зачем 
вообще применять фигурные скобки в УВЕ? 


Получение значений параметров в методах действий 


Как уже известно, методы действий могут принимать параметры. При вызове плат- 
формой АЗРМЕТ МУС методу действия должны передаваться значения всех его парамет- 
ров. Одним из мест, откуда можно получить значения, является коллекция Вочкерака. 
АЗРМЕТ МУС просматривает словарь Уа1щез в Вопкерака в поисках пары “ключ/зна- 
чение”, имя которой совпадает с именем параметра. 

Таким образом, если есть метод действия вроде показанного ниже, то его параметр 
со1ог будет заполнен согласно сегменту {со1ог}, выделенному из входящего ОВГ: 


роБ11с АсЕ1опВезо1е 11$ (3Ег1п9 со1Тог) 
{ 
// Какое-то действие 


} 


Извлекать входные параметры из словаря ВКосеерафа непосредственно потребу- 
ется редко (методы действий обычно не нуждаются в доступе к Воскерака.\Уа1щез [ 
"НекотороеЗначение"]). Имея параметры метода действий с соответствующими име- 
нами, можно рассчитывать, что они будут заполнены значениями Вопеерата, которые 
представляют собой значения, извлеченные из входящего ОВТ.. 

Точнее говоря, параметры метода действий не просто извлекаются непосредственно 
из Вооферака .\Уа10щез, а получаются через систему привязки модели, которая способна 
создавать и предоставлять экземпляры объектов любого типа .МЕТ. включая массивы и 
коллекции. Дополнительные сведения об этом механизме вы получите в главах 9 и 11. 


Использование настроек по умолчанию 


Значение по умолчанию для {со1ог} не было задано, поэтому он стал обязатель- 
ным параметром. Элемент Вопке отныне не соответствует запросу /Сафа1о9. Однако 
этот параметр можно сделать необязательным, добавив к объекту РеЕаз1+5$ следую- 
щий код: 


гоцсез.Ада (пем Коисе ("Саба1о0ч/{со1ог}", пем МусВоцееНап91ек()) 
{ 
РеЁао1%5$ = пем Коофе\уа1аер1сЕ1ораку( 
пем { сопЕго]1ег = "Ркодисез", асЕфоп = "1456", со1ок=(5Ех119) пи! } 


}); 
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С помощью МарВолее можно применить эквивалентное сокращение: 


топфез .МарБочцее (по11, "Сага109/{со1ог}", 
пеи { сопЕго]1ег = "РкобисЕз", асЕ1оп = "Газе", со1ог = (36:14) пи11 } 


На заметку! При конструировании анонимно типизированного объекта компилятор С# должен вы- 
водить тип каждого свойства из заданного значения. Значение по11 не относится к какому-то 
определенному типу, поэтому его понадобится привести к чему-то специфическому, или же 
будет получена ошибка компиляции. Вот почему мы пишем (зЕт1п9) по11. 


Теперь этот элемент Вооее соответствует как /Сафа104, так и /Саба1од/окапде. 
Для ОКЕ /Сафа1о9 значение Конъерафа.Уа]щез ["со1ог"] будет равно пи11, в то вре- 
мя как для ОНТ. /Сафа1о9/огапде — "огапде". 

Если требуется установить отличное от пи11 значение по умолчанию, как в случае 
параметров типов, не допускающих по11, например, 10%, это можно сделать вполне 
очевидным образом: 


гоиеез.Ааа (пем Воие ("Саба1о049/{со1ог}", пем МусвочЕеНапа1ехк ()) 
{ 
РеЁаз1&5 = пем Коцее\уа1иер1сЕ1опаку ( 
пем { сопёго11ех = "Ргодасез", асё1фоп = "15%", со1огх = "Ве1де", раде =1 } 
) 
}); 


Обратите внимание, что значения “по умолчанию” здесь заданы для некоторых 
“параметров”, которые в действительности не соответствуют параметрам в фигур- 
ных скобках внутри ОР. (те. сопего11егт, асе1оп и раде, хотя в шаблоне ОБТ, отсут- 
ствуют {сопеко11ек}, {асё1оп} и {раде}). Это вполне допустимый и совершенно 
правильный способ установки значений Воисерата, которые действительно зафик- 
сированы для данного элемента Коисе. Например, для данного объекта Воофе зна- 
чение Вопсерафа ["сопЕго11ехг"] всегда равно "Ркодис®з" независимо от входяще- 
го ОВГ, поэтому сопоставление запросов всегда будет обрабатываться контроллером 
РГОдОсЕзСопего11ег. 

При использовании обработчика МусВопкеНарпа1егк (как это делается по умолчанию 
в АЗРМЕТ МУС) нужно обязательно иметь значение по имени сопЕго11ек, иначе кар- 
кас не будет знать, что делать с входящим запросом, и сгенерирует ошибку. Значение 
сопЕго11ег может быть взято из параметра УЕ! в фигурных скобках или же указано в 
объекте ОеЁац143, но не может быть опущено. 


Использование ограничений 


Иногда может понадобиться добавить дополнительные условия, которым должен 
удовлетворять запрос, чтобы соответствовать определенному маршруту. Примеры пе- 
речислены ниже. 


® Некоторые маршруты должны соответствовать только запросам СЕТ, но не РОЗТ 
(или наоборот). 


® Некоторые параметры должны соответствовать определенным шаблонам (напри- 
мер, ‘параметр идентификатора должен быть числовым”). 


® Некоторые маршруты должны соответствовать запросам, которые поступили от 
обычными веб-браузерами, в то время как другие должны соответствовать тому 
же УВЕ, но присланному устройством 1РНопе. 
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Для таких случаев в Вопее предусмотрено свойство СопзЕга1п&з. Это еще один сло- 
варь Воосе\а1 иер1сь1опагу“, в котором ключи соответствуют именам параметров, а 
значения — правилам для этих параметров. Каждое правило ограничения имеет тип 
зЕк1пд и интерпретируется как регулярное выражение. Для большей гибкости оно так- 
же может быть специальным ограничением типа ТВоиеСопзега1ипе. Рассмотрим не- 
которые примеры. 


Сопоставление с регулярными выражениями 


Для того чтобы гарантировать, что параметр будет числовым, можно использовать 
такое правило: 


гоптез.АаЯ (пеи Воцке ("АгЕ1с1ез/{1а}", пем МусВопееНапа1Тек ()) 
{ 


Рерау1%$ = пем Кооке\Уа1тертс®1опаку ( 
гем { сопего11ек = "Аге1с1ез", асёТоп = "5Вом" } 


), 
СопзЕга1пЕз = пем Воцее\а1аер1сЕ1опаку (пем { 1а = @"\а{1,6}" }) 


}); 
Приведенный выше код эквивалентен следующему: 


гопбез .МарКойсе (пи11, "АгЕ1с1ез/ {1а}", 
рем { сорЕго11ег = "Агё1с1ез", ас®ё1ор = "5ром" }, 
пем { 14 = 6"\а{1,6}" } 

); 

Согласно этому правилу проверки достоверности любое потенциальное значение 14. 
сопоставляется с регулярным выражением "\а&{1,6}", которое означает “число, имею- 
щее от одного до шести десятичных разрядов”. Таким образом, элемент ВоцЕе будет 
соответствовать /АгЕ1с1е$/1 и /АгЕ1с1ез/123456. но не /АгЕ1с1ез (потому что значе- 
ние по умолчанию для 14 не предусмотрено}, /АгЕ1с1ез/хуй и /Аг%1с1е$/1234567. 


Внимание! При написании регулярных выражений на С# помните, что символ обратного слэша 
(\) имеет специальное значение как для компилятора С#, так и для синтаксиса регулярного 
выражения. Регулярное выражение, обозначающее десятичное число, должно записываться не 
как "\@", а как "\\@" (двойной обратный слэш говорит компилятору С# о том, что нужно вы- 
вести одиночный обратный слэш, а за ним а, а не управляющий символ 9). Допускается также 
писать @"\ а" (символ @ отключает интерпретацию специальных символов компилятором в 
данном строковом литерале). 


Сопоставление с методами НТТР 


Если необходимо, чтобы элемент Вопее соответствовал только запросам СЕТ (но не 
запросам РОЗТ), можно воспользоваться встроенным классом НЕЕрМеевоЧ9Сопзекалпе 
(который реализует интерфейс ТВоофеСопзЕга1п"), например: 


тоцеез.АаЯЯ (пем Воце ("Ат 1с1ез/{1а}", пем МусКооееНапа1ехг ()) 
{ 


РеРац1&3 = пем Воосеуа1аер1се1опаку ( 
рем { сопего11ек = "АгЕ1с1ез", асЕ1оп = "5Вом" } 


), 


1 Если для регистрации элементов маршрута используется распгиряющий метод Марвоцте (), 
он принимает параметр обес по имени сопз®ха1п*з. Этот параметр “за кулисами” авто- 
матически преобразуется в Кон еУа1ер1с&1олагу. 
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СопзЕга1лпЕз = пем ВоиееУа1аер1се1опаку ( 


пем { ВЕЕРМефрвоя = пем НЕЕрМмеЕНо9Сопзекалиь ("СЕТ") } 
) 
}); 


Более кратко это можно выразить с помощью МарВобте (): 


гоибез .МарВочте (по11, "АгЕ1с1ез/{1а}", 
пеи { сопего11етг = "Агё1с1ез", асбтой = "5рои" }, 
пем { ВЕЕРМе®Воа = пем НЕЕрМефвоаСопзЕгали+ ("СЕТ") } 
); 


Если требуется установить соответствие с любым из возможных методов НЛТР, пере- 


дайте их конструктору НЕЕРМеевно@Сопзе галп+, например, пех НЕЕрМеевод9Сопзегалие ( 
"СЕТ", "ОЕЪЕТЕ"). 


Совет. НЕЕРМекпо9Сопзега1тЕ функционирует независимо от того, какое ключевое значение со- 
держится в словаре СопзЕга1пЕз, поэтому в данном примере можно заменить НЕЕрмеевоа 
любым другим именем ключа. Никакой разницы не будет. 


Обратите внимание, что НеЕрМмеевоЯСопзга1пе никак не связан с атрибутом 
[АссерЕУегьз], который использовался в предыдущих главах, даже несмотря на то, что 
оба он регламентируют прием запросов СЕТ или РОЗТ. Отличия состоят в следующем. 


® НЕсрМеспояСопзЕга1пе работает на уровне маршрутизации, затрагивая только 
то, какому элементу маршрута данный запрос должен соответствовать. 


® [Ассере\Уегрюз] работает на более позднем этапе в конвейере, когда маршрут уже 


сопоставлен, экземпляр контроллера создан и запушен, и контроллер уже решил, 
какой из его методов действий должен обработать запрос. 


Если цель состоит в определении, что конкретный метод действия обрабатывает за- 
просы СЕТ или РОЗТ, используйте [Ассер&УетЪз], потому что атрибутами легко управ- 
лять, и они могут быть нацелены на один определенный метод действия. в то время 
как дополнительные ограничения маршрутизации неконтролируемо усложняют общую 
конфигурацию маршрутизации. 


Сопоставление со специальными ог раничениями 


Если необходимо реализовать ограничения, которые не являются простыми регу- 
лярными выражениями для параметров ОНТ, или ограничениями допустимых методов 
НТТР, можно реализовать собственный интерфейс ТВочкеСопзЕга1пте. Это обеспечит 
максимум гибкости в поиске соответствия с любыми данными контекста запроса. 

Например, для установки элемента маршрута. который соответствует только запро- 
сам от определенных веб-браузеров, можно создать следующее специальное ограниче- 
ние (самые интересные строки выделены полужирным): 


ру11с с1аз$ ОзегкАчепеСопзека1тпе : ТВоцеесопзегалие 
{ 
рг1уасе эег1пач _геди1геабоюзЕт1па; 


ру611с ОзегАдепеСопзЕга1их (зЕг1па геда1геЯд$о6зег1т9) 
{ 
$515. гедо1кеа5оюз(т1п9 = геао1кеаборзет1иа; 
} 
раБ11с Рроо1 МабсЬ (НЕЕрСопеехЕВазе БЕЕрСопеехе, Вопёе гопее, зЕг1па рагапМапе, 
Вонсеуа1аер1сЕ1опаку уа1щез, Вочеер1кес®1от гопке01гес®1оп) 


{ 
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1Е (БеЕрСопеехе.Веслезе.ОзегАдеп® == пи11) 
тебагп Еа15е; 
гевигп ЬЕЕрСопеех® .Веаиез® .ОзегАдеп® .Сопфа1п5 (_хеда1кеЯ$ 5119); 


На заметку! Параметр хочеер1 гесЕ1ор указывает на одно из двух действий: сопоставление 
входящего ЦВЕ (ВоцЕер1кесе1оп .Тпсой1паВедиезЕ) или генерация исходящего УВЕ 
(Воотер1кесЕ1оп.0х1бепегаЕ1оп). Ради согласованности зтот параметр рекомендуется 
игнорировать. 


Следующий элемент маршрута будет сопоставляться только с запросами, которые 
поступают от устройств {Рнопе: 


гопбез.Ааа (лем Вопте ("Аге1с1ез/ {1&а}", пем МусвоитеНнапа1ет ()) 
{ 
РеЁаз1Е$ = пем ВосееуУа1ае01сЕ1опакгу ( 
пем { сопего11ег = "А’ё1с1ез", асЕё1топ = "5Вои" } 
), 
Соп5&га1пе5 = пех ВосбеУа1аер1с1опаку ( 
пем { 1а = 6"\а{1,6}", азехАдепе = пеи ОзехАдерЕСоп5®га1т® ("1РНопе") } 


) 
}); 


Прием списка параметров переменной длины 


До сих пор для каждого элемента маршрута принимался только фиксированный 
набор параметров в фигурных скобках. А что если необходимо создать впечатление 
произвольности структуры каталогов, чтобы можно было принимать такие ОЕТ, как 
/АтЕ1с1ез/5с1епсе/Ра1еопео1оду/Р1позаигз/5Еедозаиги$? Сколько параметров в 
фигурных скобках в этом случае нужно поместить в шаблон ОКЕ? 

Система маршрутизации позволяет определять универсальные параметры, которые 
игнорируют слаши и захватывают все до конца ОВГ. Такие параметры назначаются до- 
бавлением префикса — звездочки (*), например: 


гоцеез .МарВоц®е (п11, "Ах1с1е5/{*аг®1с1еРафЬ}", 
пем { сопего11етг = "А’Е1с1ез", асетоп = "ром" } 


)% 


Этот элемент маршрута будет соответствовать /АгЕ1с1ез/5с1епсе/Ра1еопко1оду/ 
1 позаигз/Зедозаикиз, порождая значения маршрута, которые перечислены в табл. 8.6. 


Таблица 8.6. Значения ВочЕераеа, подготовленные универсальным параметром 


Ключ Воцеерафа Значение Боцферафа 

СопЕго11ех Аге1с1е$ 

асЕ1оп ЗВом 

агЕ1с1еРраЕВ 3с1епсе/Ра1еопео1оду /Рлпозаиг$/5Еедозаиги$ 


Естественно, в шаблоне ОБТ, может быть предусмотрен только один универсальный 
параметр, и он должен быть последним (крайним правым) в ОБЕ, поскольку он пере- 
хватывает весь путь ОЁТ, от этой точки и до конца. Однако он не перехватывает все из 
строки запроса. Как упоминалось ранее, объекты Кочфе просматривают только путевую 
часть ОВ.. 
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Универсальные параметры удобны, если вы позволяете посетителям выполнять на- 
вигацию по некоторого рода иерархии произвольной глубины, как в системах управле- 
ния содержимым (сог{еп{ тапаяетлепе зузет$ — СМ$). 


Сопоставление с файлами на жестком диске сервера 


Общая цель маршрутизации — разрушить ассоциацию “один к одному” между ОВГ. и 
файлами в файловой системе сервера. Однако система маршрутизации все равно про- 
веряет файловую систему в поисках соответствия входящего ОН! некоторому файлу на 
диске. Если соответствие найдено, система маршрутизации игнорирует запрос (пропус- 
кая любые элементы марптрута, которым также может соответствовать ОБ!) и обраща- 
ется к файлу непосредственно. 

Это очень удобно для статических файлов вроде графических изображений, таблиц 
стилей С5$ и файлов кода Зауа$ сре. Их можно сохранить в текущем проекте (напри- 
мер, в папках /СопеепЕ или /3сг1р\), после чего обращаться и обслуживать напрямую, 
как если бы маршрутизации вообще не было. Поскольку файл определенно присутству- 
ет на диске, он имеет приоритет перед конфигурацией мартрутизации. 


Использование флага КонфеЕх1 $ Е1паЕ1Лез 


Если вместо этого необходимо, чтобы конфигурация маршрутизации имела при- 
оритет перед файлами на диске, установите свойство ВоЕеЕх13Е119Е11ез объекта 
ВоиЕеСо11есе1ол в Е гие (по умолчанию оно равно Еа15е). 


рур11с зтаЕ1с уо1а Кес1зтегвоЕез (ВочкеСо11есЕ1оп гои®ез) 
{ 


// Это можно установить перед или после настройки элементов маршрута: 
хгочее5 .ВоцееЕх15411п09Е11ез = &гое; 


Когда ВоцтеЕх15Е1п9Е11ез равно Егие, система маршрутизации не ищет совпаде- 
ние ОВГ с реальным файлом на диске; взамен она пытается найти и вызвать соответ- 
ствующий элемент ВопееТаь]1е .Воцкез. В этом случае есть только две причины для 
непосредственной обработки файла. 


® Когда входящий ОБ. не соответствует ни одному элементу маритрута, но соответ- 
ствует файлу на диске. 
® Когда применяется ТопогеВоиее () (либо имеется какой-то другой злемент мар- 


шрута, основанный на ЗЕорБопЕ1пчНапа1ет). Ниже это рассматривается более 
подробно. 


Установка ВоисеЁх1 3 1п9Е11ез в Егие — довольно радикальная мера, и вряд ли она 
подойдет в большинстве случаев. | 

Например, обратите внимание, что элемент маршрута {сопЕго11ех}/{асЕ1оп} так- 
же соответствует /Солеепе/зту1ез.сзз. В результате система больше не сможет об- 
рабатывать файл С$$, а вместо этого вернет сообщение об ошибке, уведомляющее о 
невозможности обнаружения класса контроллера по имени СопепЕСопЕго11ек. 


На заметку! вочееЕх1 зЕ1п9Е11ез — средство системы маршрутизации, поэтому оно влия- 
ет на запросы, только если система маршрутизации активна (т.е. на запросы, передаваемые 
через Ог1Воче1п9Модо1е). Для сервера И$ 7, запущенного в режиме интегрированного 
конвейера, и для 1$ 6 с соответствующей картой шаблонов зто будет касаться каждого за- 
проса. Но в других сценариях развертывания (например, 1$ 6 без карты шаблонов) модули 
ТНЕЕЮМодо1е участвуют, только когда УВЕ имеет соответствующее расширение (например, 
*.азрх, * .азрх), так что запросы *.сз3 (и прочих нединамических файлов} не пройдут че- 
рез маршрутизацию, а будут обработаны статически, независимо от ВоиеЁх1$(1п9Е11е$5. 
Подробнее о картах шаблонов и отличиях между 1$ би ИЗ 7 будет рассказано в главе 14. 


Глава 8. ЦВЕ и маршрутизация 233 


Использование ТапогеВочте () Для 
обхода системы маршрутизации 


Для установки в пространстве ОБТ. специфических исключений, предотвращающих 
сопоставление с определенными шаблонами в системе маршрутизации, служит метод 
тдпогекоиее (). Ниже показан пример его применения: 


рую11с зЕаЕ1с уофа Вед1зфегКочЕез (ВоиЕеСо11есЕ1оп гооез) 
{ 

гоцфе5 .ТдпокеВоцее (" {Е11епате}.ху="); 

// Остальная часть конфигурации маршрутизации 


} 


В приведенном примере { Е11епаше } .ху? трактуется как шаблон ОКГ. подобно нор- 
мальному элементу марптрута, поэтому система маршрутизации не будет игнорировать 
запросы /Б1ав.хух или /Еоо.ху7?зоще=СтрокаЗапроса. (Разумеется, этот элемент 
должен быть расположен в таблице маршрутов выше любого другого элемента, с ко- 
торым может произойти совпадение и который обработает эти ОВТ.) Если необходим 
более тонкий контроль над ЧЕГ, игнорируемыми при маршрутизации, можно также 
передать параметр сопзЕга1п($. 

ТопогеКочее () полезно в следующих ситуациях. 


® Имеется специальный ТНефрНапа]1ек, зарегистрированный для обработки за- 
просов *.хух, и ему не должна мешать система маритрутизации. (В стандартном 
проекте АЗРМЕТ МУС эта техника используется для защиты запросов *.аха от 
вмешательства со стороны системы маритрутизации.) 


® Свойство ВочееЕх15119Е11ез установлено в Егпе, и также требуется настро- 
ить исключение для этого правила (например, чтобы все файлы из /СопеепЕ 
обслуживались непосредственно с диска). В этом случае можно воспользоваться 
гои(е5 .ТопогевВоиее ("СопЕепЕ/ {*хезеоЕОкт}"). 


Совет. Во многих приложениях нет необходимости в вызове ТопогекКочее () , хотя исключение 
по умолчанию для *.ах@ имеет смысл оставить. Не стоит тратить время на то, чтобы специ- 
фически исключать части пространства ОРЕ, если на то нет веских причин. Если входящий УВЕ 
в действительности не соответствует одному из установленных злементов маршрута, система 
просто выдаст ошибку 404 МоЁ Роипа (не найдено). 


Как все это работаел? Внутри метода ТдпогеКоцее () устанавливается элемент мар- 
шрута, обработчик Воиенапо1егк которого является экземпляром ЗЕорвонЕ1па9Напа1ек 
(вместо Мусвоч+еНапо1ег). Фактически приведенный пример в точности соответствует 
следующему: 

гообез.Ааа(пек Войте (" {Ё11епапе}.хул", рем ЗЕорвосЕ1та9Нало1ек ())); 


Система марнтрутизации жестко закодирована на поиск ЗЕорВоне1паНапа] ет и 
распознает его как сигнал для обхода марпрутизации. ЗЕорВопЕ1паНапа]ет можно 
использовать в качестве обработчика маргпрутов в собственных маршрутах и классах 
ВопЕеВазе, когда требуется установить более сложные правила отключения маршрути- 
зации для определенных запросов. 


5 Это не означает, что запрос будет отклонен вообще; это значит лишь, что он не будет пе- 
рехвачен системой маршрутизации. Ответственность за. обработку такого запроса будет 
передана серверу П$, что может привести к генерации ответа, а может и не привести, в 
зависимости от того, имеется ли другой зарегистрированный обработчик для этого ЧЕ. 
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Генерация исходящих ЦВЕ 


Обработка входящих ОВТ, — только половина дела. Посетители сайта нуждаются 
с навигации от одной части приложения к другой, и чтобы они могли это делать, их 
понадобится снабдить ссылками на другие действительные ОБ! внутри схемы ОБТ, 
приложения. 

Старый способ построения ссылок состоит просто в конкатенации их из фрагмен- 
тов строк и жестком кодировании во всем приложении. Именно это и делалось в тече- 
ние многих лет в приложениях АЗРМЕТ \еБЕогпаз и на большинстве других платформ 
разработки веб-приложений. Программистам известно о существовании страницы по 
имени Рееа115.азрх, которая ищет параметр строки занроса по имени 14, поэтому ис- 
пользуется жестко закодированный ОВ, вроде следующего: 


пуНурегт фик .Мау1да(е0т] = "-/рефа115.азрх?1а=" + 1ешто; 
Эквивалент в представлении МУС будет выглядеть так: 
<а пкеё=" /РходисЕ$/0ека113/<$= У1емрака ["Тсешто"] %>">Моге дера11$</а> 


Этот ЧБ будет работать в настоящее время, но как насчет его работы в буду- 
щем, после проведения рефакторинга, когда захочется применить другой ОБЬ для 
РкобисЕ5СопЕго11ех или его действия река1152? Все существующие ссылки будут на- 
рушены. А как быть с построением сложных ОВГ, со множеством параметров, включаю- 
щих специальные символы и управляющие последовательности? 

К счастью, система маршрутизации предлагает лучший способ. Поскольку схема 
ОБЕ явно известна платформе и внутренне представлена в виде строго типизирован- 
ной структуры данных, можно воспользоваться преимуществами различных методов 
встроенного АРГинтерфейса для генерации хорошо оформленных ОЕ, не прибегая к 
их жесткому кодированию. Система маршрутизации может восстановить активную 
конфигурацию маршрутизации, определив во время выполнения, какой ОБ!, приводит 
посетителя к определенному контроллеру и методу действия, и каким образом встроить 
любые параметры в этот ОБТ. 


Генерация гиперссылок с помощью 
вспомогательного метода НЕм1 .АсЕтопт арк 


Простейший способ генерации ОБТ, и их визуализации в виде нормальной гипер- 
ссылки НТМГ предусматривает вызов вспомогательного метода НЕп1.АсЕ1опГ1 ок () из 
шаблона представления. Например, показанный ниже вызов визуализирует согласно 
текущей конфигурации маршрутизации гиперссылку на ОБТ, который укажет на дей- 
ствие 113% класса контроллера РеобисЕ5Сопеко11 ег: 


<%$= НЕмТ.АсеторГ1пк ("Зее а11 оЕ опт ркодисЕз", "1156", "Ркодасез") $%> 


При конфигурации маршрутизации по умолчанию в результате получится такая 
гиперссылка: 


<а птеё="/Ргобисе5/11в5">5ее а11 оЕЁ сиг ргодисев</а> 


Обратите внимание, что если не указать контроллер (те. вызвать НЕт1 .АсЕлорт1 ик ( 
"Зее а11 оЁ ок ргодасез", "Г зе") ), то по умолчанию это предполагает ссылку на 
другое действие в том же контроллере, который выполняется в данный момент 

Это намного яснее, чем жестко кодированные ОВТ, и манипуляции со строками. Но 
что более важно, это решает проблему изменения схемы ОБТ. Любые изменения в кон- 
фигурации маршрутизации будут немедленно отражены в сгенерированных подобным 
образом ОВ!. Это также лучше и с точки зрения разделения ответственности. 
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По мере роста приложения маршрутизация (те. задача выбора ОВЬ для иденти- 
фикации контроллеров и действий) часто выделяется в совершенно отдельную ответ- 
ственность, связанную с размещением обычных ссылок и переадресаций между пред- 
ставлениями и действиями. При каждом помещении ссылки или переадресации не 
потребуется думать о том, какой метод действия должен быть вызван для посетителя. 
Автоматическая генерация исходящих ОБТ, помогает избежать смешивания этих видов 
ответственности, сводя к минимуму возможные недоразумения. 


Передача дополнительных параметров 


Элементу маршрута при необходимости можно передавать дополнительные специ- 
альные параметры?: 


<®= НЫп1.АсеторГлик ("ВеЯ 1еетз", "Т1зЕ", "РгодасЕ8“, 
рем { со1охг="ВеЯ", раде=2 }, по11) %> 


При конфигурации маршрутизации по умолчанию приведенный вызов НЕ1. 
АСЕ1опЬлик приведет к генерации следующей гиперссылки: 


<а БхеЕ=" /Рходисе$/Т18%?со1ох=Ведвапр;раде=2">Веа 1%етз</а> 


На заметку! Символ амперсанда (&) в ЦВЕ кодируется как &атр ; . Это необходимо для того, чтобы 
полученный в результате документ соответствовал стандарту ХНТМЬ (в ХМЕ символ & указывает 
на начало ссылки на сущность ХМИ). Браузер интерпретирует &атр; как &, поэтому когда поль- 
зователь щелкает на ссылке, браузер издает запрос к /РхофасЕз/113Е?со1ох=Вед&раде=2. 


Если же конфигурация маршрутизации содержит маршрут Ркодасе$/Т15Е/ 
{со1ог}/ {расе}, тот же код сгенерирует гиперссылку, которая показана ниже: 


<а БгеЕ=" /РходасЕз/Т13Е/Веа/2">Вей 1Еепз</а> 


Обратите внимание, что при маршрутизации для исходящих ОЕГ параметры встав- 
ляются в ОВГ, если существует параметр в фигурных скобках с соответствующим име- 
нем. Однако если соответствующего параметра нет, к строке запроса добавляется пара 
-имя/значение”. 

Как и при поиске соответствия с входящим маршрутом, во время генерации исходя- 
щих ОБТ всегда выбирается первый совпадающий элемент маршрута. Вместо попыт- 
ки отыскать наиболее специфичный элемент маршрута (те. с ближайшей комбинацией 
параметров в фигурных скобках в ОКП), поиск прекращается после нахождения любого 
объекта ВооЕеВазе, который предоставит ОЕ! с указанными параметрами маритрути- 
зации. Это еще одна причина для того, чтобы размещать более специфичные элементы 
в таблице маршрутизации перед более общими! Дополнительные сведения об этом ал- 
горитме будут даны далее в этой главе. 


Обработка значений параметров, устанавливаемых по умолчанию 


Если ссылка производится на значение параметра, которое является его значением 
по умолчанию (в соответствии с подходящим элементом маршрута), то система стара- 
ется избежать вставки его в генерируемый ОВ!.. Это значит, что будут получаться более 
чистые и короткие ОВГ.. Например, приведенный ниже вызов НЫп1 .АсЕфопГ пк: 


<®= НЕт.Асеторь1пк ("Ргодасев Ропераде", "Тидех", "Ркодисез")} %> 


5 Последний параметр (для которого указано значение по11) позволяет дополнительно специ- 
фицировать атрибуты НТМГ, которые будут визуализированы в НТМЕ-дескрипторе. 
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визуализирует следующую гиперссылку (предполагается, что Тидех — значение по 
умолчанию для ас 1 оп): 


<а БтеЕ="/Ркодисез">Ртодасев Вопераде</а> 


Обратите внимание, что здесь генерируется ОНТ, вида /Ркодосез, а не /РгодосЕз/ 
Тпдех. Было бы бессмысленно включать Тпдех в ОБТ, поскольку он и так сконфигури- 
рован по умолчанию. 

Это касается в равной мере всех параметров со значениями по умолчанию (в кон- 
тексте маршрутизации никаких специальных исключений для параметров сопЕго11ег 
или асЕ1оп не делается). Разумеется, опускать можно только непрерывные последова- 
тельности значений по умолчанию в правой части строки ОНТ, а не в ее середине; в 
противном случае ОК!. будет оформлен неверно. 


Генерация полностью определенных абсолютных ИВЕ 


Обычно метод НЕт1.АсЕлопг+ ик () генерирует только путевую часть ОЫ, (те. 
/РгодасеЕ$, а не ВЕЕр: //мии. ехапр1е . сош/Ргодасе3). Однако для него предусмотрено 
несколько перегрузок, которые генерируют полностью определенные абсолютные ОВТ. 
Наиболее полная, всеобъемлющая перегрузка выглядит следующим образом: 


<%= НЕ .АсетопГлик ("С11ск пе", "МуАСЕ1опл", "МуСорего11ег", "БЕЕрз", 
"уулу. ехатр1е.сой", “апсрогМате", пем | рагаш = "уа1ое" }, 
пем { шуабЕгИаЕе = "зотееЬ1ра" }) %> 


Если повезет, то вам не придется использовать этот жутко выглядящий код очень 
часто, но если уж доведется, то он визуализирует гиперссылку вида: 


<а пуа Е х1рабе="зошеЕеН1та" 
Втеё="БЕрз: //мии.ехапр1е . соп/Мубопеко1Тек/ МуАсЕ1оп?рагалеуа1ое#апсвогМапе"> 
С11ск пе</а> 


После развертывания приложения в виртуальном каталоге имя каталога также поя- 
вится в нужном месте сгенерированного ОБТ. 


На заметку! Система маршрутизации в Зузтеш. мер . ВоцЕ1па не поддерживает концепцию пол- 
ностью определенных абсолютных РЕ. Она имеет дело только с виртуальными путями (т.е. путе- 
вой частью ЦРЕ, указанной относительно корня виртуального каталога). Продемонстрированная 
выше возможность построения абсолютных ЦВЕ была добавлена в методы-оболочки АЗРМЕТ 
МУС. Возможно, какая-то будущая версия ЗузЕеш. мер . ВочЕ1па будет поддерживать фор- 
мирование абсолютных УРЕ. В этом случае появится возможность, например, указать, что оп- 
ределенный маршрут, скажем, к странице входа в систему, связан с протоколом ВЕЕре; тогда 
все ссылки на этот маршрут автоматически специфицировали бы абсолютные ЦВЕ. с протоко- 
лом ВЕЕрз, а все ссылки со страницы входа в систему — УВЕ с протоколом НЕЕр. Но пока что 
переключение пользователей в режим НТТР$ и обратно осуществляется вручную. 


Генерация ссылок и ЦВЕ из чистых данных маршрутизации 


Как известно, система маршрутизации предназначена не только для АЗРМЕТ МУС, 
поэтому она не придает специального значения параметрам по имени сопего11ет или 
асЕ1оп. Однако все методы генерации ОВГ, которые были показаны до сих пор, требу- 
ют спецификации явного метода действия (например, Нет .Асе1опЬ1ик() всегда при- 
нимает параметр асЕ1оп). 

Иногда параметры сопЕго11ех или асе] оп удобно трактовать не как специальные 
случаи. а рассматривать их наравне с любыми другими параметрами маршрутизации. 
Например, в главе 5 навигационные ссылки строились из объектов МауГ4пк, которые 
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содержали произвольные коллекции данных маршрутизации. Для таких сценариев 
существуют альтернативные методы генерации ОВГ, которые не вынуждают тракто- 
вать сопего11ег или асЕ1 оп как специальные случаи. Они принимают произвольную 
коллекцию параметров маритрутизации и сопоставляют их с текущей конфигурацией 
маршрутизации. 

ным .вопеег1пк () — это эквивалент Н&и1 .АсЕ1опЬ тик (). Например, код 


<= НЫ .ВомеергаюК("С1АсСК ше", рем { сорЕто11етх = "Рхо@исе$", асетоп = "Рае" }) %> 


генерирует следующую гиперссылку (при конфигурации маршрутов по умолчанию}: 


<а вгеЕ=" /Рходасе$/Т15%">С11ск ше</а> 


Аналогично 0г1.Воое0т1 () представляет собой эквивалент Ог]1.АсЕтоп () . 
Например, код 


<*= 0г1.ВоиЕе0г1 (пем { сопеко11ег = "Ркобосе$", асЕ1оп = "ТЕ" }) $> 
визуализирует такой ОБИ. (при конфигурации маршрута по умолчанию): 
/РхоаосЕ$/11 5 


В приложениях АЗРМЕТ МУС эти методы применяются нечасто. Однако важно 
знать, что в вашем распоряжении есть такая гибкость на случай, если она понадобится 
или если это упростит код (как это было в главе 5}. 


Перенаправление на сгенерированные ЦВЕ 


Наиболее распространенной причиной для генерации ОКГ является визуализация 
гиперссылок НТМГ. Вторая наиболее распространенная причина — когда мегод дейст- 
вия желает издать команду перенаправления НТТЁ которая командует браузеру немед- 
ленно перейти на другой ОБТ. в приложении. 

Чтобы осуществить перенаправление НТТР, просто верните результат вызова 
вед1гесЕТоАсЕ1 ол (), передав ему целевой контроллер и метод действия: 


ру611с АсЕтопВево1е МуАСЕТопМееьоя () 
{ 


тероти Веа1хесЕТоАсЕ1 опт ("Ъ1зЕ", "Ркоаисьв"); 


} 


Вызов вернет Вед1хесеТовочееВези1%, который во время своего выполнения ис- 
пользует внутри методы, генерирующие ЧБ, чтобы найти корректный ОЕ! для этих 
маршрутных параметров, и затем издает перенаправление НТТР 302 по этому ЧВГ. Как 
обычно, если контроллер не указан (например, гебикп ВеЯ1гесеТоАсЕ1 оп ("Т15%"))}, 
предполагается использованием другого действия на том же контроллере, который вы- 
полняется в данный момент 

В качестве альтернативы с помощью Ве91гесеТоВоаее () можно специфицировать 
произвольную коллекцию маршрутных данных: 


рую11с Асе1опВево1Е МуАСЕ1оПМефвоя () 
{ 
теготп Веа1гесеТовоцее (лем { асе1фоп = "ботеАс® топ", сизсомегта = 456 }); 


} 


На заметку! Когда сервер реагирует на перенаправление НГР 302, никакой другой код НТМЕ в по- 
ток ответа клиенту не посылается. Позтому вед1гесЕТоАсЕтоп () можно вызывать только из 
метода действия, а не из страницы представления, как зто возможно с НЕм1.АсеторЬайк(); 
если хорошо подумать, то нет никакого смысла в отправке перенаправления 302 из середины 
НТМЕ-страницы. Два основных типах перенаправлений НТТР (301 и 302) более подробно рас- 
сматриваются далее в зтой главе. 
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Если вместо перенаправления НТТР необходимо просто получить ОБТ. в виде строки, 
то для этого можно вызвать 0Ог1.АсЕТоп () или 0:1.ВопЕе0к1 () из кода контроллера, 
нанример: 


руб11с АсетопВезо1ь МуАСЕ1опМеевоа () 

{ 
5Ех1па ик1 = 0:1 .Асе1оп ("ботеАселоп", пеи { сивфопекта = 456 }); 
// ... теперь делайте что-то с пгт 


Алгоритм сопоставления с исходящим маршрутом 


Примеров генерации исходящих ОБТ, до этого момента приводилось вполне доста- 
точно, чтобы обрести начальное понимание. Но поскольку конфигурация маршрутиза- 
ции может включать множество элементов, возникает вопрос: каким образом принима- 
ется решение о том, какой из элементов использовать при генерации ОРГ из заданного 
набора значений маршрутизации? Действующий алгоритм характеризуется рядом тон- 
ких особенностей, которые желательно знать на случай возникновения неожиданного 
поведения. 

Как и при сопоставлении с входящим маршрутом, просмотр стартует с начала таб- 
лицы маршрутов и продолжается вниз, пока не попадется первый объект ВопЕеВазе, 
который вернет отличный от пи11 ОВ, для заданной коллекции значений маршрути- 
зации. Стандартные объекты ВопЕе возвращают отличный от пи11 ОВГ, только при со- 
блюдении следующих трех условий. 


1. Объект ВочЕе должен быть в состоянии получать значение каждого из своих па- 
раметров в фигурных скобках. При этом он будет брать значения из любой из сле- 
дующих коллекций, перечисленных в порядке их приоритетов. 


а) Явно заданные значения (те. значения параметров, которые указываются при 
вызове метода генерации ОБТ). 


6) Значения Воокерака из текущего запроса (за исключением значений, появ- 
ляющихся в шаблоне ОНТ, после тех, для которых новые значения были заданы 
явно). Более подробно это поведение обсуждается ниже. 


в) Значения из коллекции реЕао1+з. 


2. Ни одно из явно предоставленных значений параметров не может противоречить 
значениям параметров объекта Коце, устанавливаем “только по умолчанию”. 
Параметр только по умолчанию — это такой, который присутствует в коллекции 
РеРаи1Е5$ данного элемента, но не появляется в списке параметров в фигурных 
скобках птаблона ОВТ. Поскольку вставить в ОБТ, значение, отличное от установ- 
ленного по умолчанию, возможности нет, элемент маршрута не может описать 
такое значение, и потому не находит соответствия. 


3. Ни одно из значений выбранных параметров (включая унаследованные от 
Воитерафа текущего запроса) не нарушает ограничения. записанные в свойстве 
Соп5{га1пЕз$ объекта Вооее. 


Первый объект Вопфе, удовлетворяющий этим критериям, произведет отличный от 
0111 ОНТ, и на этом процесс генерации ОВГ завершается. Выбранные значения пара- 
метров будут подставлены на место соответствующих заполнителей в фигурных скоб- 
ках, а остальные значения по умолчанию будут отброшены. Если указываются любые 
явные параметры, которые не соответствуют параметрам в фигурных скобках или па- 
раметрам по умолчанию, они будут визуализированы как набор пар “ключ/значение” 
строки запроса. 
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Проясним картину: каркас не пытается выбрать наиболее специфичный элемент 
таблицы маршрутизации или шаблон ОВ!.. Он прекращает поиск, встретив первое сов- 
падение; поэтому всегда придерживайтесь “золотого правила” маршрутизации — раз- 
мещайте более специфичные элементы перед менее специфичными. Если совпадение 
произошло с нежелательным элементом, то либо переместите его вниз по списку, либо 
сделайте более специфичным (например, добавив ограничения или удалив значения ио 
умолчанию), чтобы в дальнейшем исключить подобного рода совпадения. 


Повторное использование параметров текущего запроса 


На шаге 1(6) описанного выше алгоритма упоминалось о том, что система маршрутизации будет 
повторно использовать значения параметров из текущего запроса, если новые значения явно не 
указаны. Это довольно нетривиальное поведение, к которому нелегко привыкнуть (об этом сви- 
детельствуют часто задаваемые вопросы на форумах по АЗРМЕТ М\С), и зто, вероятно, не то, 
на что следует полагаться на практике. Тем не менее, о таком поведении следует знать, чтобы в 
булущем не возникало сюрпризов. 


Например, рассмотрим следующий элемент маршрута: 
тоиЕез .МарБоцЕе (по11, "{сопЕго11ет} / {асЕ1оп} /{со1ог}/ {раде}"); 


Предположим, что пользователь в данный момент находится на УВЕ /СаЕа1о9/Ъ15Е/ 
Ригр1е/123, и генерируется такая ссылка: 


<*%= НЕЙ .АСЕТОПГТик("С11сКк ме", "Т1зЕ", "Саба1оч", пем {раде=789}, по11) %> 


Генерацию какого УВЕ следует ожидать? Может показаться, что совпадения с элементом маршру- 
та вообще не произойдет, потому что {со1ок} является обязательным параметром (не имею- 
щим значения по умолчанию), для которого при вызове НЕп1 „.АСЕлорЬаиК () не было указано 
никакого значения. 


Однако на самом деле совпадение для зтого элемента будет найдено, и результат выглядит сле- 
дующим образом: 


<а вхеЕ=" /Сафа1о9/Т15Е/Ригр1е/789">С11ск пе</а> 


Как видите, система маршрутизации повторно использует текущее значение параметра {со1ог} 
(которое равно Рихр1е, так как посетитель находится в данный момент на УВЕ /СаЕа1о9/ 
Т13Е/Ригр1е/123). Так получается из-за того, что для параметра { соток} не было задано 
другое значение. 


Еще один специальный случай 


Возникает один интересный вопрос: что произойдет, если в аналогичной ситуации будет сгене- 
рирована следующая ссылка: 


<®= Н1.АсбфортАлКк("С11сКк ще", "Газе", "Сафа1Тод", пем {со1от="Аачиа"}, по11) %> 


Может показаться, что поскольку для {раде} значение не было указано, будет использоваться 
параметр {раде } текущего запроса. Увы, но это не так. Система маршрутизации повторно ис- 
пользует значения только тех параметров, которые в шаблоне УВЕ находятся перед параметрами 
с заданными измененными значениями (подобно тому, как {со1ог} встречается ранее {разде} 
в {со1ог} / {раде}). В этом случае совпадение с элементом маршрута вообще не будет найдено. 


В этом есть своя логика, если воспринимать УРЕ как пути в некоторой универсальной файловой 
системе. Чаще всего интересуют связи между различными элементами в одной папке, но очень 
редко — между одноименными элементами из разных папок. 


Подытожим: поведение системы маршрутизации в отношении повторно используемых параметров 
из текущего запроса довольно необычно, с еще более необычным специальным случаем. Если вы 
полагаетесь на это поведение, то код будет очень трудно понять. Намного безопаснее и яснее при 
генерации ссылок указывать явные значения для всех специальных параметров маршрутизации. 
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Генерация гиперссылок с помощью метода 
НЕ] . Асе1опТ1пК<Т> и лямбда-выражений 


Генерация гиперссылок с использованием вспомогательного метода НЕт1 .АсЕ1оп 
Тлик() предпочтительнее манипуляций жестко закодированными строками, но этот 
способ не слишком безопасен в отношении типов. Здесь средство НщеШш$Зепзе не помо- 
жет специфицировать имя действия или передать ему корректный набор специальных 
параметров. 

В сборке МУС ЕКивагез, находящейся в библиотеке МускозоЕ+.меь.Мус. а11. содер- 
жится обобщенная перегрузка метода НЕш1 .АСЕЗоптяик<т> (). Вот как выглядит ти- 
пичный его вызов: 


<%= НЕ] .АСЕтопГиК<РкодисЕ$Сопеко11ет> (х => х.11$6(), "А11 ргодасЕз") $> 


В резульгате получается следующая гиперссылка (при конфигурации марирутиза- 
ции по умолчанию): 


<а ВкеЕ=" /Ркодасе/Т152">А11 ргодисев</а> 


На этот раз обобщенный метод АСЕтойтак<т> принимает обобщенный параметр т. 
специфицирующий тип целевого контроллера. Метод действия задается лямбда-выра- 
жением на этом типе контроллера. В действительности лямбда-выражение никогда не 
выполняется. Во время компиляции оно превращается в структуру данных, просмат- 
риваемую во время выполнения системой маршрутизации для определения метода и 
параметров, на которые произведены ссылки. 


На заметку! Чтобы все это работало, шаблон представления должен импортировать простран- 
ство имен, в котором определен класс РкобисЕ$Сопего11 ег, а также пространство имен 
М1скозоЕЕ Мер .Мус. Для зтого в начало файла представления АЗРХ следует лобавить 
<%$@ ТирокЕ Матезрасе="..." %>. 


Благодаря НЕш1 .АсЕ1опГ1тК<Т> (), вы получаете строго типизированный интерфейс 
для схемы ОВ! с полной поддержкой со стороны средства ПтеШЗепзе. Большинство но- 
вичков усматривают в этом значительные преимущества, но на самом деле возникают 
проблемы как технического, так и концептуального характера. 


® Должны импортироваться корректные пространства имен в каждый шаблон 
представления. 


® При попытке ввода лямбда-выражения внутри блока <%= ...$> в версии \1з0а| 
Эёлао 2008 $Р1 средство пиеШЗепзе часто не работает: 


® Метод НЕп1.АсЕтопТ1иКк<тТ> () создает впечатление, что можно сослаться на 
любой метод любого контроллера. Однако иногда это невозможно, потому что в 
конфигурации марпгрутизации может отсутствовать маритрут к нему, или же сге- 
нерированный ОБТ, может вести к другой перегрузке метода действия. В общем, 
метод НЕт1 .АсЕ1оп[ГЛиК<Т> () может ввести в заблуждение. 


® Строго говоря. действия контроллера — это именованные фрагменты функцио- 
нальности, а не методы С#. В АЗРМЕТ МУС предусмотрено несколько уровней 
расширяемости (например, фильтры), из чего следует, что входящее имя действия 
может быть обработано методом С# с совершенно несвязанным с ними наиме- 
нованием (соответствующий пример будет показан в следующей главе). Лямбда- 
выражения не могут представить это, поэтому гарантировать правильную работу 
Нем .АсЕ1опГ1оК<Т> () нельзя. 
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Было бы замечательно, если бы метод НЕ1 .АсЕфорГ4ок<т> () гарантированно рабо- 
тал правильно, так как преимущества строго типизированного АРГ-интерфейса и под- 
держки со стороны Н\еШ5епзе действительно очевидны. Однако есть масса спенарисв, 
когда он не работает, и поэтому создатели МУС поместили это средство в сборку МУС 
Еифагез, а не в основной пакет АЗРМЕТ МУС. Пока перечисленные недостатки не бу- 
дут преодолены в будущих версиях платформы, вероятно, лучше его пока не исполь- 
зовать, а вместо зтого придерживаться обычных, основанных на строках перегрузок 
НиТ .АсеторьЬлик {). 


Работа с именованными маршрутами 


Каждому элементу маршрута можно назначить уникальное имя, например: 


гочсез.Ада {"Апфгапее", пем Войее ("зТаЕЕЁ/ {асе1оп}", пем Мусвочеенаратег {))} 
{ 


РеЁао1Е$ = пем ВочбеУа1иер1с1опаку(пем ( сопего11ех = "5фаЕЕНопе" }) 


}); 
С помощью МарВочте () можно записать зквивалентный, но более краткий код: 
тоцсез .МарКоиее ("1пЕгапее", "зфаЕЕ/{ас®1оп}", пем { сопеко1Лег = "бфаЕЕНоме" }); 


В любом случае зтот код создает именованный злемент маршрута 1п{гапе\. В чем 
смысл именования элементов маршрута? В некоторых случаях это может облегчить ге- 
нерацию исходящих ОВГ.. Вместо того чтобы размещать элементы маршрута в правиль- 
ном порядке, чтобы платформа находила нужное автоматически, необходимый злемент 
можно просто указать по имени. Имя маршрута можно специфицировать при вызове 
Отт.Воифе0т1 () или НЕм1 .КоцфееГ1пКк(), например: 


<$—= Нет .Бонбер1ик ("С11ск ме", "дрегалее", пеи { асё1оп = "зкаЕЕГа" }) *> 


Независимо от наличия других элементов в конфигурации маршрутизации, этот сге- 
нерирует следующую гиперссылку: 
<а пгеЁ="/ зтаЕЕ/5раЕЕТ15е">С11ск пе</а> 


Без именованных маршрутов было бы трудно гарантировать, что и входящая, и 
исходящая маршрутизация всегда выберут нужный маршрут. Иногда кажется, что 
корректный порядок приоритетов для входных соответствий конфликтует с порядком 
приоритетов для генерации исходящих ОКТ. В таких случаях определять, какие ограни- 
чения и значения по умолчанию обеспечат требуемое поведение, приходится опытным 
путем. Именование маршрутов снимает проблему упорядочивания — они просто выби- 
раются по имени. Иногда такой подход приносит очевидную выгоду. 


Причины, по которым именованные маршруты не используются 


Вспомните, что одним из преимуществ генерации исходящих ОБТ, является разде- 
ление ответственности. При каждом помещении ссылки или перенаправления необ- 
ходимо думать не об ОБ!, а только о том, на какой метод действия должен попасть в 
конечном итоге посетитель. К, сожалению, именованные маршруты мешают в дости- 
жении этой цели, потому что они вынуждают думать не только о месте назначения ка- 
ждой ссылки (те. о действии), но также и о механизме ее достижения (те. об элементе 
маршрута). 

Если удается избежать назначения имен элементам маршрута, получается более 
“чистая” система в целом. В зтом случае появится возможность построить набор мо- 
дульных тестов, которые проверят как соответствие входящих ОВГ, так и генерацию 
исходящих (это уже делалось в главе 5 для приложения ЗрогЗоге), воспринимая эту за- 
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дачу как совершенно отдельную ответственность. Запоминать или управлять именами 
элементов маршрута не понадобится, поскольку все они анонимны. При размещении 
ссылки или перенаправления можно просто указать целевой метод действия, позволяя 
системе маршрутизации обрабатывать ОЕТ. автоматически. В общем, применять име- 
нованные маршруты или нет — вопрос персональных предпочтений. Но в любом случае 
зто лучше, чем жестко закодированные ОКМ 


Модульное тестирование маршрутов 


Маршрутизацию не всетда легко конфигурировать, но очень важно делать это пра- 
вильно. Если в ВоскеТаЪ1е .Вопфез присутствует изрядное количество элементов, то 
при изменении одного из них или добавлении нового может быть нечаянно нарушен 
какой-то элемент. К, счастью, тестирование маршрутов проводится довольно несложно, 
так как система маршрутизации имеет очень ограниченный диапазон возможных вход- 
ных и выходных данных. 

В главе 5 модульные тесты для входящей и исходящей маршрутизации прило- 
жения Эрог$®юге строились с использованием служебных методов Тез(Вон(е {} и 
СесОчЕБоппЯ0к1 (). Однако вы могли не обратить на них внимания или не заметить, 
что эти методы могут повторно использоваться и в других проектах. Давайте вернемся 
к ним еще раз и посмотрим. как они могут помочь протестировать вновь созданную 
конфигурацию маршрутизации. По ходу дела также будет рассмотрено несколько более 
широких принципов модульного тестирования, включая стратегию применения тесто- 
вых дубликатов в сравнении с использованием инструментов имитации. 


На заметку! Если вы пока еще не знаете, с чего начать модульное тестирование, как выбрать 
необходимые инструменты и как добавить тестовый проект в решение, вернитесь к главе 4, 
где обсуждалось модульное тестирование для приложения Зрой юге. С другой стороны, если 
вы уже настолько хорошо знакомы с модульным тестированием и имитацией, что приведенная 
далее дискуссия покажется тривиальной, просто вскользь просмотрите код. 


Тестирование входящей маршрутизации УВЕ 


Как вы должны помнить, получить доступ к конфигурации маршрутизации можно 
через общедоступный статический метод Вед1зкегВоцеез (). определенный в С1офа1. 
азах.сз. Поэтому базовый тест маршрута может выглядеть следующим образом: 


[ТезеР1хЕоге] 
рУ611с с1а55 ТибоппаВоцЕеМаесв1т9 
{ 
[ТезЕ] 
роб11с уо1а ТезЕЗботевол“*е () 
{ 
// Подготовка: получить конфигурацию маршрутизации 
// и установить тестовый контекст 
ВопЕеСо11есЕ1оп копееСопЕ1 = пем ВопееСо11есЕ1оп (); 
МусАрр11са 1 оп.Вед1зегВопее$ (гопееСопЕ14)}; 
НЕЕрСопфехЕВазе ЕезСопфехе = Как-то получить экземпляр 


// Действие: запустить механизм маршрутизации на данном НЕрСопеех(Вазе 
Вопферафа гопбераба = гопеСопЕ1а.СеЕВосерафа (ЕезЕСопеехе); 
// Утверждение 
Аззеге. т3МоеМ№11 (гообераса, "МОТ, Кооберабса маз гебогпей"); 
// Возвращен Вопеерафа, равный по11 
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Аззеге .ТзМ№\М№М111 (гоцеерафа.Воцфе, "Мо гопее маз шафсВей"); 
// Совпадающие маршруты отсутствуют 
// Добавить другие утверждения для проверки правильности этого ВБоч+ерафа 
} 
} 


Самая загадочная часть здесь — получение экземпляра НеЕрСопеехЕВазе. 
Разумеется, код тестов не должен быть привязан к какому-либо контексту реального 
веб-сервера (позтому Зузкем.Меь.НеерСопеехе не используется). Вместо этого следует 
предусмотреть специальный тестовый экземпляр НеЕрСопеехеВазе, создав тестовый 
дубликат или имитацию. Ниже рассматриваются оба приема. 


Использование тестовых дубликатов 


Первый способ получения экземпляра НЕЕрСопеехЕВазе состоит в написании 
собственного тестового дубликата. По сути, это означает наследование класса от 
НЕЕрСопЕехЕВазе и создание тестовых реализаций только тех методов и свойств, кото- 
рые на самом деле используются. 

Ниже приведен минимальный тестовый дубликат, которого достаточно для тестиро- 
вания входящей и исходящей маршрутизации. Он пытается делать минимум возмож- 
ного, реализуя только те методы, которые действительно вызываются маршрутизацией 
(это можно определить методом проб и ошибок). Однако эти реализации представляют 
собой липть немногим более чем заглушки. 


риб11с с1азз ТезЕНЕЕрСопеехе : НебрСопеехЕВазе 
{ 
ТезеНЕЕрКечиез® (езВедаезк; 
ТезЕНЕЕрКезропзе сезЕВезропзе; 
рыр11с оуегг19е НЕЕрВечиезЕВазе Ведиезе { деё { гекагп тез(Веааез®; } } 
р9Б11с оуегг1де НЕЕрВезропзеВазе Везропзе { деё { хебаки тез(Везроп$е; } } 
руБ11с ТезеНЕЕрСоптехе (3Ег1пд иг1) 
{ 
фезЕВедаезЕ = пем ТезЕНЕЕрКедаез* () { 
_АррВе1а&1уеСаггепЕЕ хесоЕ1отЕ11еРаеВ = иг1 
}; 
фезЕВезропзе = пем ТезЕНЕЕрВезропзе (); 
} 
с1аз55 ТезеНЕЕрВесаезе : НЕЕрВедаезВазе 
{ 
риб11с эзЕг1па _АррВе1аЕ1уеСигтеп&Ехеси1о0Е11еРаеь { деЕ; зек; } 
риуб11с оуегг1ае зЕх1пд АррВе1аЕ1уеСиггепЕхесиЕ1опЕ11еРаев 
{ 
деЕ { гебагп _АррВе1а 1уеСагхеп Е хеси®1опЕ11еРаЕН; } 
} 
руб11с оуегг1ае эЕхг1пд Арр11са 1опРаЕВ { деё { гекагп по11; } } 
руб11с оуегк1ае 5Ег1па Ратио { дее { гебаки пи11; } } 
} 
сТаз$ ТезеНЕЕрКезропзе : НЕЁрВезрорзеВазе 
{ 
РиуБ11с оуегг14е 5&г1пд Арр1уАррРаВМо91 Е1ет (36х10а х) { хебиги х; } 


} 


Теперь, используя тестовый дубликат, можно написать полный тест: 


[Тез] 
руБ11с уо19 Гогмага51азЬбоезТоНоцетТпадаех () 
{ 
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// Подготовка: получить конфигурацию маршрутизации 

// и установить тестовый контекст 

Воп$еСо11есЕ1оп гоибеСопЕ19 = пем ВКопееСо11есЕ1оп (); 
МУСАрр1 1 саЕ1оп .Кеч1зтегВои{е$ (гопееСопЕ19) ; 
НЕЕрСопфехЕВазе +ез+Сопфехе = пем ТезенНЕрСопфех ("-/"); 


// действие: запустить механизм маршрутизации на данном НЕЕрСопеехЕВазе 
Воцеерафа гопбераба = гопбеСопЕ1а.сСеЕВоиТерака (фезЕСопеехе); 


// Утверждение 
Аззеке. Т5МоМо11 (гообераба, "МОЬЬ Вочбераба маз гесогпей"); 
// Возвращен Восберафа, равный пи11 
Аззеке. Т3М№о<М11 (гочберафа.Вопее, "М№о гойбе маз табсВей"); 
// Совпадающие маршруты отсутствуют 

Аззеге.Агекала1 ("Ноше", гонферафа.Уа1лез ["сопЕго11ех"], "Ихгопд сопёхоЛег"); 

// Неверный контроллер 
Аззехг*.АгеЕдиа1 ("Тп4ех", гооферафа.Уа1лез ["асф1оп"], "Игопд ас&1оп"); 

// Неверное действие 


} 


Перекомпилируйте и запустите заново тесты в графической среде МОпй. Должна 
появиться полоса зеленого цвета. Это докажет, что ОБТ, / обработан действием Тпаех 
на НомеСопЕко11ек. 


Использование среды имитации (Мод) 


Второй из двух основных способов получения объекта НЕЕрСопфехЕВазе предпола- 
тает использование среды имитации, которая позволяет программно строить имити- 
риуюшие объекты. Имитирующий объект похож на тестовый дубликат, но с тем етличи- 
ем, что он генерируется динамически во время выполнения, а не явно записывается в 
коде как обычный класс. Перед использованием среде имитации необходимо сообщить, 
какой интерфейс или базовый класс планируется имитировать, и указать, как имити- 
рующий объект должен реагировать на вызовы его избранных членов. 

В главах, посвященных приложению Зрой$фоге, приводились примеры примене- 
ния среды имитации под названием Мод. Сборка „МЕТ по имени Мод. а11 для этой сре- 
ды доступна для бесплатной загрузки по адресу ВЕЕр : //со@е .доод1е .сош/р/мода/. 
Поместите сборку в удобное место и установите ссылку на нее из проекта Тез (также 
понадобится добавить оператор и31п9 Маа;). 

Теперь можно написать тест вроде следующего: 


[ТезЕ] 

рир11с у01а Еогмага51азБбоезТоНомеТподех () 

{ 
// Подготовка: получить конфигурацию маршрутизации 
// и установить тестовый контекст 
Копесо1ТесЕ1ой гопееСопЕ1а = пем КопеСо11есеЕтоп (); 
МусАрр11сае1оп .Кед15(етКопее$ (гоиЕеСопЕ194) ; 
уахг москНЕЕрСопфехе = МакКеМоскНЕЕрСопфех+ ("-/"); 


// Действие: запустить механизм маршрутизации на данном НЕЕрСопеехЕВазе 
Восфераеа гоцферафа = госфеСопЕАд .сеЕеВопферафа (посКНЕЕрСопеехе.ОБЬ)ес+); 


// Утверждение 

Аззеке. ТзМо №11 (косберафа, "МОГ Вообераеа маз гесагпей"); 

АззегЕ. Т5МоМо11 (гочбераса.Воиее, "Мо гоа®е миаз па®спей"); 
АззекЕ.АгеЕста1 ("Номе", гоцберафа.Уаез ["сопетго11ехг"], "Ихора сопехо1Тег"); 
АззегЕ.АгеЕаца1 ("Тпдех", гоифберафа.Уа1ае$ ["асЕ1оп"], "Икопд ас®1опт"); 
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Реализация метода МаКеМоскнЕЕрСоп®ех" () показана ниже: 


ретуабе зса с Моск<НеЕрСопеехЕВазе> МакемоскнЕЕрСопеехЕ (зЕг1па пг1) 
{ 


уаг поскНеЕрСопсехЕ = пем Моск<НЕЕрСопфехеВазе> (); 


// Имитировать запрос 

уаг поскВечаезЕ = пем Моск<НЕЕрВеаиезеВазе> (); 

шоскнЕЕрСопеехЕ . бебир (х => х.Бедиез®) .Вебагпз (поскВеаиезе .ОБ)есЕ); 
поскВесаезЕ .бетур (х => х.АррВе1а1\еСиггепЕхеси1отЕ11еРаеВ) .Вебагиз (0т1); 


// Имитировать ответ 
уаг посквезропзе = пем Моск<НЕЕрВезропзеВазе> (); 
поскнЕЕрсопЕехЕ .5ееир(х => х.Везропзе) .Вегагиз (поскКВезропзе.ОЬ3есЕ); 
поскВезропзе.5ееир (х => х.Арр1ТуАррРаЮМосд1 Е1ет (1&.ТзАпу<5Ег1па> ())) 
.Вебигп$<$г1па>(х => х); 
гебагп поскНЕЕрСопеехе; 
} 


Учитывая, не пришлось писать тестовые дубликаты НЕЕрСопеехЕВазе, НЕСрВедиез(Вазе 
и НЕЁрвезропзеВазе, здесь кода меньше, чем ранее. Разумеется, все это можно егце бо- 
лее упростить, оставив в каждом методе [ТезЕ] только код, специфичный для тестов: 


[ТезЕ] 
руЮ11с уо1а Еогмаг9$1азНСоезТоНнопетпдех () 
{ 


ТезЕВоисе ("-/", пем { сопего11ех = "Ноте", асб1фоп = "Тпдех", 1а ме: 


} 


Весь вспомогательный код можно вынести в отдельный метод: 


рУрю11с Коифераба Тез(Воцее (зЕгАпа их1, оБ]есе ехресфед\уа1иез) 

{ 

// Подготовка: получить конфигурацию маршрутизации и установить тестовый контекст 
КоибеСо11есе1оп гоибеСопЁ1а = пеи ВоипееСо11есЕ1он (); 

МусАрр11сае1оп .Вед1зкетгВоцеез (гоотесопЕ19) ; 

уаг поскНЕЕрСопфехЕ = МакеМоскНЕЕрСопеехе (пг1); 


// Действие: запустить механизм маршрутизации на данном НЕбрСопсехеВазе 
Вочеераба гоибераба = коибеСопЕ19 .сеЕвочеерафа (тоскНЕЕрСопеехе.ОЮ]ес®); 
// Утверждение 
Аззеге. Т5Мо №011 (гообераба.ВКоцфе, "Мо коцее маз паесВей"); 
уаг ехрескеяар1сЕ = пем Вочбе\уа1иер1сЕ1опагу (ехрескеаУа1щез); 
Еогеасб (уаг ехресееаУа1 1п ехресееЯр1с®) 
{ 
1Е (ехрессеЯУа1 .\Уа1ае == пи11) 
Аззехге.ТзМ№11 (гообера{а .\Уа1щез [ехрескей\а1.Кеу]); 
е15е 
Аззеге.АгеЕаца1 (ехрескедУа1 .Уа1ае.ТобЕк1па (), 


гонферафа .\Уа1аез [ехресее@\а1.Кеу] .ТоЗек1па ()); 
} 


гебиги коцеербафа; // ... на случай, если будут добавляться 
// какие-то другие утверждения 


} 


На заметку! Обратите внимание, что когда ТезъКочте () сравнивает ожидаемые значения мар- 
шрута с реальными (на фазе утверждения), он преобразует все в строки, вызывая . То5Ек1 па (). 
Очевидно, что УВЕ могут содержатьтолько зЕх1па (не 10 иличто-то еще), ноехрескеЯУа1щез 


может содержать 1п (например, { раде = 2 }). Однако сравнивать имеет смысл только стро- 
ковые представления каждого значения. 
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Теперь можно добавить метод [ТезЕ] для добавления в каждую форму входящего 
ОВ небольшой порции повторяющегося кода. 

Тестирование не обязательно ограничивается только сопего11ег. асЕ1оп и 1а: при- 
веденный выше код одинаково хоропто работает с любыми специальными параметрами 
маршрутизации. 


Тестирование генерации исходящих ЦВЕ 


Можно также тестировать и генерацию приложением исходящих ОЕ. на основе су- 
ществующей конфигурации. Это требуется. например. в ситуациях, когда для публич- 
ной схемы ОВГ, предусмотрен контракт который никогда не должен изменяться, кроме 
как намеренно. 

Это несколько отличается от тестирования совпадения с входящим маршрутом. То, 
что определенный ОВ!, отображается на определенный набор значений Вочкерахка, еще 
не значит, что тот же самый набор значений Воосерафа будет отображен обратно на 
этот же ОВ! (совпадающих элементов маршрута может быть несколько). Наличие пол- 
ного набора тестов для входящей и исходящей маршрутизации окажет незаменимую 
помощь при каждом изменении конфигурации марптрутизации. 

Для тестирования генерации исходящих ОВГ. можно использовать тот же тестовый 
дубликат, что и ранее: 


[Тез®] 
риб11с у01а ЕЯ1ЕРгодасе50 ТзЗАЕ РгодасЕз Е91е_50() 
{ 
\У1гЕепа1РаеВрафа гези1%Е = Сепегкаке0х1\У1аТезЕРосЬ1е ( 
пеи { сопЕго11ег = "РгодасЕз", асЕ1ор = "ЕЯ1", 19а = 50 } 
); 
Аззеге.АкеЕаца1 ("/РгодисЕ$/Е91Е/50", гезо1+е .\У1гаа1РаЕВ); 
} 
рефуаке У1кЕоа1Ра\БРафа Сепегаке0х1\1аТезерооЮТе (об]есЕ уа1аез) 
{ 
// Полготовка: получить конфигурацию маршрутизации и тестовый контекст 
ВоцееСо11есЕ1ой гопееСопЕ1а = рем ВоикеСо11есЕ1ол (); 
МусАрр11са1оп .Вед1зеегКоцеез$ (гопееСопЕ1а); 
уаг сезЕСореехЕ = пем ТезЕНЕрСопеехе® (пи11); 
ВедаезСопфехЕ сопеехЕ = пеи ВеацезСопеех® (ЕезЕСопфехе, пем Вочберафа()); 


// Действие: сгенерировать ОВЬ 
гебаки гоцеесопЕ1а .Сее\У1кЕма1Раей (сопеехе, пем ВоцкеУаТаер1с®1опаку (уа1аез)); 


} 


Вкачестве альтернативы можно не связываться с тестовым дубликатом НЕЕрСопсехЕВазе. 
а вместо этого создать имитированную реализацию на лету. 
Просто замените бсепегасе0х1\/1аТезБосЬ1е () на Сепегаее0к1\1аМоскз (): 


рефуаее У1гроа1РаЕПраба Сепегасе0к1\1аМосК$ (об]есе уа1тез) 
{ 
// Подготовка: получить конфигурацию маршрутизации и тестовый контекст 
ВоцееСо11есЕЛой гоибеСопЕ1а = пем ВочееСо11ес1оп (); 
МусАрр1 1саЕ1оп.Кед1зЕетВоп{е$ (гочсеСопЕ19а) ; 
уаг посКкСопфех+ = МаКеМосКНЕЕрСопфехе (по11); 
КеаиезЕСопеехе сопеехе = пем ВечиевЕСопфех® (поскСопеехе. ОБдес®, пех Восфераёа ()); 


// Действие: сгенерировать ОВЬ 
тееаги годееСопЕ1 9 .бек\У1 коа1РаЕп (сопеехе, пеи Вочбе\уа1аерасе1опахгу (уа1аез)); 
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Обратите внимание, что метод МакеМоскнЕЕрСопеехЕ () определен в предыдущем 
примере имитации. 


Дальнейшая настройка 


К зтому моменту вы уже видели большую часть того, что делает основная маршру- 
тизация, и как ее применять в приложении АЗРМЕТ МУС. Теперь давайте рассмотрим 
несколько точек расширения, которые с помощью которых открываются дополнитель- 
ные возможности в расширенных сценариях использования. 


Реализация специального элемента Воп+еВазе 


Если вам не нравится способ сопоставления стандартных объектов Вон+е с ОВ, или 
необходимо реализовать что-то необычное. можно создать альгернативный класс, унас- 
ледовав его непосредственно от БоцкеВазе. Это дает полный контроль над процессами 
сопоставления входящих ОЕ1, извлечения параметров и генерации исходящих ОВ|.. 
В этом случае потребуется предоставить реализации двух методов. 


® сеЕвоптерата(НеерСопЕехеВазе БЕЕрСопеех®). Это механизм сопоставления 
входящих ИВТ. Данный метод вызывается на каждом элементе воокетаь1е. 
КопЕез по очереди, пока он не вернет отличное от п11 значение. Для того что- 
бы специальный элемент маршрута соответствовал заданному БЕЕрСопеесе 
(например, после просмотра БЕЕрСопеехе. Вечиезе.Рае1), необходимо вер- 
нуть структуру Вопеерака, описывающую выбранный ТВопЕеНапа1ег (обычно 
Мускои{еНата1ет) и все извлеченные параметры. В противном случае должно 
возвращаться значение по11. 


® СеЕ\/1гтоа1Рать (ВедиезЕСопфехЕ геадиезеСоптехе, КоцсеУа1аер1сЕ1опаку 
уа1це5). Это механизм генерации исходящих ИЕ!. Данный метод вызывается 
на каждом элементе КоптеТаю1е .ВоцеЕез по очереди, пока он не вернет отлич- 
ное от пи11 значение. Чтобы получить ОВ, для заданной пары гедоезеСопеехе / 
уа1лез, понадобится вернуть объект У1тЕпа1Расьрака, описывающий вычислен- 
ный ОВ. относительно корня виртуального каталога. В противном случае должно 
возвращаться значение по11. 


Разумеется, специальные объекты кочкеВазе и обычные объекты Воп+е можно 
смешивать в пределах одной конфигурации маршрутизации. Например, при замене 
старого веб-сайта новым коллекция старых ОБТ, которые должны поддерживаться в 
новом сайте (чтобы не наруптить входящих ссылок) может оказаться дезорганизован- 
ной. Вместо настройки сложной конфигурации маршрутизации, которая распознает 
диапазон унаследованных шаблонов ОВГ, можно создать единственный специальный 
элемент ВочфеВазе, который будет распознавать специфические унаследованные ОВ, 
и передавать их определенному контроллеру на обработку: 

118109 Зузсет.Г1па; 

ручЮ11с с1а5$ Тедасу0тк15Воцее : ВопееВазе 

{ 

// На практике это можно извлекать из базы данных 
// и кзшировать в памяти 
ре1уафе зкаЕ1с эег1па[] 1едасу0г13 = пеи зЕг4иоа[] ( 
"-/агЕ1с1ез/тау/хеюга-Чап1о-Веа1ЕВ-ЕАрз.ре1", 
"-/агЕ1с1ез/\е1ос1гаркогСа1епдаг.раЕ", 
"- /далаез/ Е. зэка В /Ви119уУоцхОийРС Е4пта1.азр" 
}; 
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раЮ11с оуегг14е Воссера®а СеЕВопеерВафа (НЕЕрСопеехЕВазе ПЕЕрСопеехЕ) 
{ 
зЕг119 иг1 = БЕЕрСопеехе .Веадцезе .АррВе1а 1уеСиггепеЕ хесоЕ1опЕ1ТеРаеВ; 
1Е (1едасу0к15 .Сопба1пз (их1, 5&глидСотрагег .Ога1па1ТопотесСазе)) { 
Коисераба г@ = пем Вонберафа (61$, пем МусКоиееНапа1ет()); 
та.Уа1аез.Ааа ("сопего11ет", "ГедасуСопеепте"); 
та.У\Уа1аез.Ааа("аст1оп", "Напд1ерГедасу0т1"); 
та.Уа1ез.Ада ("пу1", иг1); 
гебигп га; 
} 
е!тзе 
тебагп по11; // Не унаследованный ОВЬ 
} 
ру611с охегг1ае У1гЕиа1РаеПРафа сеЕе\/1геча1РаЕВ ( 
ВечиезЕСопеехЕ кеаоезЕСопеехе, Конее\уалер1сЕ1опаку уа1щез) 
{ 
// Этот элемент маршрута никогда не генерирует исходящие ОБЬ 
гебакп по11; 


} 


Зарегистрируйте этот элемент в начале конфигурации маршрутизации, обеспечив 
его приоритет перед другими элементами: 


рую11с эзкаЕ1с уо1а Вед15фекгВопеез (КоцкеСо11есЕ1оп гоиеез) 
{ 
гоцЕез$ .Тапогевойте (" {гезоцгсе}. аха/ { *раЕВТиЕо}"); 
гоцЕе$ .АЧа (пех Бедасу0тг1$5Воцфе()); 
// ... прочие элементы маршрута 


} 


После этого вы обнаружите, что любые унаследованные ОЕ! будут обрабатываться 
методом действия Напа1еЪедасу0к1 {) контроллера Гедасубоп еп СопЕго11ет (пред- 
полагая, что он существует). Все прочие ОНТ, будут сопоставляться с остальной частью 
конфигурации маршрутизации. как обычно. 


Реализация специального обработчика маршрутов 


Во всех приведенных до сих пор примерах марптрутизации для свойства ВосбеНапо1ет 
класса Копее использовался обработчик Мусвоц(еНап 1екг. В большинстве случаев это 
именно то, что и требуется, поскольку МусвочееНапд1ег — это стандартный обработ- 
чик маршрутов платформы МУС, которому известно, как находить и вызывать классы 
контроллеров. 

Тем не менее, система маршрутизации позволяет при желании применять специаль- 
ные обработчики на основе ТВоссеНапа1екг. Их можно использовать для отдельных мар- 
шрутов или любых их комбинаций. Применение специального обработчика маршрута 
позволяет перехватить управление обработкой запросов на очень ранней стадии: сразу 
после маршрутизации и непосредственно перед запуском любой части механизмов МУС 
Егатоемогк. После зтого можно заменить остальную часть конвейера обработки запро- 
сов чем-то другим. 

Ниже приведен пример очень простой реализации специального обработчика на ос- 
нове ТВоцтеНап Тег, который записывает результаты непосредственно в поток ответа: 


ру611с с1азз Не11оМог19Нарпа1екг : ТВоббеНапо1ет 


{ 
руб11с ТНЕЕрНапа1ек СеЕНЕЕрНаро1ег (ВедиезЕСопеехЕ гедиезЕСопеех®) 
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гегагт пем Не]Т1оМог1анЕерНапа1ег(); 
} 
рт1уабе с1азз Не11ойог1анЕЕрНапа1ет : ТНЕЕрНапо1ег 


{ 
риуб11с Боо1 ТзВепзабБ1е { деЕ { хебогпи Еа1зе; } } 
рУуЮ11с уо1а РкосеззКедиез (НЕЕрСопЕехЕ сопеехЕ) 
{ 


сопсехе .Везропзе.Иг1Ее ("Не11о, мог1а!") ; 


} 
Его можно зарегистрировать в таблице маршрутов следующим образом: 
гопсез.Ада (пем Коле ("бауНе11о", пем Не11ойог1АНапо1ек ())); 


Затем этот обработчик можно вызвать, введя /бауНе11о в адресной строке браузера 
(рис. 8.2). 


Рис. 8.2. Результат вызова специального обработчика на основе ТкКозЕенапа1ех 


Здесь не применяются концепции контроллеров или действий, потому что все сле- 
дующие после маршрутизации действия происходят в обход МУС Егате\хогк. Можно 
даже создать совершенно независимую платформу веб-приложений и присоединить ее 
к корневой системе маритрутизации, что позволит пользоваться заполнителями, зна- 
чениями по умолчанию, средствами проверки достоверности маргрутов и генерации 
исходящих ОВГ. 

В главе 16 будет показано, как создается специальный обработчик на основе 
ТВопфеНап@1ег по имени ИеБГогизКоцЕеНапоа1ект, которому известно, как находить и 
вызывать страницы АЗР.МЕТ \’еЬЕогт$. Это позволит интегрировать АЗРМЕТ \е Еогт$ 
в систему маршрутизации. 


Полезные советы относительно схемы ЦР. 


Даже при наличии столь полного контроля над схемой ОНТ, все равно остается во- 
прос: с чего же начать? Как должна выглядеть правильная схема ОВГ? Ге и каким об- 
разом проявятся ее преимущества? 

С момента появления \®6Ь 2.0 несколько лет назад, многие разработчики стали отно- 
ситься серьезно к схеме ЧВГ. Было выработано несколько важных принципов, придер- 
живаясь которых, можно повысить удобство, совместимость и ранг сайта в поисковых 
системах. 


Делайте ЦВЕ ясными и дружественными для людей 


Помните, что ОВГ. — столь же важная часть пользовательского интерфейса, как 
шрифты и графика. Конечные пользователи определенно обращают внимание на со- 
держимое строки адреса браузера. Они намного увереннее будут помещать закладки и 
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обмениваться такими ОВГ, которые легко читаются и выглядят понятно. Взгляните на 
следующий ОВГ: 


ПЕЕр: //иии. атахоп.сот/ар/0471787531/геЕ=ра 555 3З34е=ОТЕ8&з=дабемау&а19=1202745736 


Захотите ли вы поделиться этой ссылкой со своими близкими? Безопасно ли с ней 
работать? Содержит ли она какую-то частную регистрационную информацию? Сможете 
вы продиктовать ее кому-то по телефону? Постоянный ли зто ЧЕ, или со временем он 
изменится? Безусловно, что все эти параметры строки запроса для чего-то нужны, од- 
нако ущерб. который они наносят удобству пользования сайтом, очевиден. Ту же самую 
страницу можно было бы получить и так: 


БЕЕр://мми. апахоп .соп/зеагсЬ-епа1пе-оре1и1таЕ1оп 


Ниже приведен список рекомендаций о том, как сделать ОВГ. дружественными для 
людей. 


® Проектируйте ОВГ. таким образом, чтобы описать их содержимое, а не детали реа- 
лизации приложения. Например, используйте /АхЕ1с1ез/Аппоа1Вероге вместо 
/Мерз1Ее_у2/СасЪедСопеепе5егуег /ЕкошСасве/Аппиа1Верог®. 


® Оздавайте предпочтение заголовкам содержимого перед числовыми идентифика- 
торами. Например. применяйте /АгЕ1с1ез/Аппиа1Верогк, а не /АгЕ1с1ез/2392. 
Если числовой идентификатор должны использоваться для того. чтобы отличать 
элементы с одинаковыми заголовками или минимизировать обращения к базе 
данных, указывайте и такой идентификатор, и заголовок (те. /АхЕ1с1ез/2392/ 
Аппиа1Верокг+}. Хоть это дольше вводится, но имеет гораздо больше смысла для 
человека, а также повышает ранг страницы в поисковых системах. Приложение 
может просто игнорировать заголовок и отображать элемент, найденный по 
идентификатору. 


® По возможности не используйте расширения имен файлов для НТМГ-страниц 
(пе. .азрх или .пус)”, а только для специализированных типов (те. .)рд, рае, 
.21р). Веб-браузеры не заботятся о расширениях имен файлов, если правильно 
установлен тип МПМЕ, но люди ожидают, что имена, скажем, РОЕ-файлов будут 
оканчиваться на „рае. 


® Когда зто имеет смысл, создавайте иерархии (например, /РгодасЕз/Мепзиеах/ 
361.&5/Вес]), чтобы посетитель мог догадаться об ОБТ, родительской категории. 


® Придерживайтесь независимости от регистра символов (некоторые захотят наби- 
рать ОВТ, читая его с печатного листа). Система маршрутизации АЗРМЕТ являет- 
ся нечувствительна к регистру по умолчанию. 


® Избегайте специализированных символов, кодов и последовательностей. Если не- 
обходим разделитель слов, используйте тире? (например. /пу-дгеак-ахк1с1е). 
Подчеркивания не являются дружественными, а закодированные в ОН, про- 
белы выглядят причудливо (как в /му+огеак+акЕ1с1е) или неуклюже (как в 
/пу$20дгеае%20ахе1с1е). 


7 Чтобы избежать применения расширений файлов для сгенерированных АЗРМЕТ МУС стра- 
ниц, сервер П5 7 должен быть запущен в режиме интегрированного конвейера, а сервер 
1$ 6 — в режиме с картами шаблонов. Более подробные сведения ищите в главе 14. 


8 дополнительную информацию о тире и подчеркиваниях можно найти по адресу: 
ми. пабесиеез .сош/Б1о9/дазрез-уз-ипдегзсогев/ 
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® Не изменяйте ОВ!.. Неработающие ссылки — это потерянные возможности. Если 
же изменений ОН. избежать не удается, сохраняйте поддержку старой схемы ОВ, 
насколько возможно долго, организовав постоянные перенаправления (НТТР 301). 


ОВ! должен быть кратким, простым для набора, читабельным для человека и посто- 
янным, к тому же он должен отражать структуру сайта. Якоб Нильсен (ФаКоь №езеп), 
гуру в области эргономики программного обеспечения, пишет об зтом в своей статье по 
адресу мм. изе1®.сом/а1ехБох/990321.Н 1. Тим Бернерс-Ли (Тип Вегпегз-Гее), изо- 
бретатель “Всемирной паутины”, дает аналогичные советы (см. ими. и3.ого/Рхоу1Чег/ 
ЗЕуте/ОВТ). 


Следуйте соглашениям протокола НТТР 


Вседозволенность в Интернете имеет долгую историю. Даже исключительно небреж- 
но составленная НТМГ-разметка может визуализироваться в браузерах с использова- 
нием наилучитих их возможностей. Точно так же и протоколом НТТР можно злоупот- 
реблять без очевидных последствий. Но, как вы вскоре убедитесь, веб-приложения, 
отвечающие стандартам, являются более читабельными. удобными в использовании и 
коммерчески более выгодными. 


Правильный выбор между запросами СЕТ и РОТ 


Существует эмпирическое правило, что запросы СЕТ должны использоваться для из- 
влечения информации только для чтения, вто время как запросы РОЗТ следует применять 
для любых операций записи, которые изменяют состояние сервера. Согласно стандартам, 
запросы СЕТ предназначены для безопасных взаимодействий (не имеющих побочных эф- 
фектов помимо извлечения информации), а запросы РОЗТ — для небезопасных взаимо- 
действий (связанных с принятием решений или изменений чего-либо). Эти соглашения 
изложены на сайте консорциума \/ЗС по адресу лу. м3 .оха/Ргоу1Чек/5ъу1е/ОВТ. 

Запросы СЕТ являются адресуемыми: вся необходимая информация содержится 
в ОВГ, поэтому на них можно размещать закладки и устанавливать на них ссылки. 
Традиционная платформа АЗРМЕТ Ме Еоптз ненадлежащим образом использует запро- 
сы РОЗТ для навигации по серверным элементам управления, что не позволяет размес- 
тить закладку или сослаться, скажем, на вторую страницу экрана Сх19У1ем. В АЗРМЕТ 
МУС дела обстоят намного лучше. 

Не используйте (и, строго говоря. не допускайте) запросы СЕТ для операций, которые 
могут изменять состояние. Многие веб-разработчики приобрели горький опыт в 2005 г., 
когда широкой публике был представлен веб-ускоритель Сообе \МеЬ Ассаегатог. Это при- 
ложение производит предварительную выборку всего содержимого каждой доступной по 
ссылке страницы, что вполне законно, поскольку запросы СЕТ` должны быть безопасны- 
ми. Но, к сожалению, многие веб-разработчики в своих приложениях проигнорировали 
соглашения НТТР и реализовали доступ к функциональности добавления и удаления из 
корзины покупок через простые ссылки. Наступил вполне предсказуемый хаос. 

В одной компании даже заподозрили, что их система управления содержимым сай- 
тов стала жертвой регулярных атак, потому что все содержимое регулярно удалялось. 
Позднее обнаружилось, что поисковая система добралась вплоть до ОН! страницы ад- 
министрирования и прошла по всем ссылкам удаления. Аутентификация могла бы спа- 
сти в такой ситуации, но только не от веб-ускорителей. 


О строках запросов 


Далеко не всегда использование аргументов строки запросов в ОН! является непра- 
вильным, но все же лучше их избегать. Первая проблема связана с их синтаксисом: 
все эти вопросительные знаки и амперсанды нарушают базовые принципы удобства 
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использования. Они просто не дружественны к посетителю-человеку. Вторая проблема 
состоит в том, что пары “имя/значение” строки запросов обычно могут быть перестав- 
лены без особых на то причин (/гезоиксе?а=1&6=2 обычно дает тот же результат, что 
и /хезоихсе?Ъ=2ва=1). Строго говоря, порядок может играть важную роль, позтому 
любая индексация по этим ЧЕ. будет трактовать их как разные. Это может привести к 
проблемам неканонического представления и снижения рейтинга в поисковых систе- 
мах (об этом речь пойдет позже). 

Вопреки распространенным мифам, современные поисковые системы при индек- 
сации ОВГ включают параметры строки запроса. Поэтому может случиться так, что 
ключевые слова, появляющиеся в части строки запроса ОВГ, будут трактоваться как 
менее существенные. Когда же необходимо применять аргументы строки запроса? Хотя 
никто не даст четких рекомендаций на этот счет, но опыт диктует их использование в 
следующих ситуациях. 


® Для экономии времени в тех случаях, когда читабельность для человека или по- 
исковая оптимизация не является главной целью, и когда не предполагается, что 
кто-то разместит закладку на странице. Примером может служить экран содер- 
жимого корзины для покупок в приложении Зрогзоге, а также, возможно, все 
внутренние, предназначенные только для администратора страницы (для них 
вполне подойдет вариант строки {сопЕхо11ег} / {асе1оп} ?рахатз). 

® Для создания впечатления передачи значений алгоритму вместо извлечения су- 
ществующих ресурсов (например, при поиске / зеагсв?аиеку=Еоо®Ъа11 или раз- 
биении на страницы /агЕ1с1ез/1136?раде=2). При построении таких ОБТ, мож- 
но пренебречь интересами поисковой оптимизации или удобства ручного ввода. 


Описанный подход, конечно же, субъективен, так что можете поступать по собст- 
венному усмотрению. 


Используйте корректный тип перенаправления НТТР 


Существуют два основных типа команд перенаправления НТТР (см. табл. 8.7). Оба 
типа команд заставляют браузер переходить на новый ОЕ. через запрос СЕТ, поэтому 
многие разработчики не обращают внимания на разницу между ними. 


Таблица 8.7. Наиболее распространенные типы переадресации НТТР 


Код ЗНЕНИЕ Интерпретация Корректное 

состояния поисковыми системами применение 

301 Перемещено постоянно (это Индексировать содер- При изменении схемы 
подразумевает, что ИВ! ус- жимое под новым ЦВ(. ОВЕ (например, ИРЕ 
тарел навсегда, никогда не Перенести все ссылки и в стиле АЗРМЕТ) или 
должен запрашиваться вновь, рейтинг страницы из старо- = для гарантии того, что 
и что все входящие ссылки го ЦВЕ в новый. каждый ресурс имеет 
должны быть обновлены но- единственный, канони- 
вым ИВ... ческий ЦВЕ. 

302 Перемещено временно (под- Сохраняет индексацию и При регулярной нави- 


разумевает, что клиент должен 
использовать замененный ЦВЕ 
только в текущем запросе, а 

в следующий раз вновь обра- 
щаться кстарому УВЕ). 


содержимое под старым 
ОВЕ". 


гации по несвязанным 
Це. 


* Дотех пор, пока не выполняется перенаправление на другое имя хоста. При таком перенаправлении по- 
исковые системы могут предположить, что вы пытаетесь похитить чужое содержимое, и проиндексирует 
его под целевым ЦВЕ. 
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В АЗРМЕТ МУС переадресация НТТР 302 используется всякий раз, когда вы возвра- 
шается объект Вед1кесеТоВоцеевези1е или Вед1хесЕВези1+. Это не является оправ- 
данием для ленивых: если есть намерение выполнить переадресацию НТТР 301, то так 
и следует поступать. Такую переадресацию можно организовать с помощью расширяю- 
щего метода для обычного класса Вед1тесеТоВочееВези1*: 


руБ11с зЕаЕ1с с1азз РегтапепЕВе 1 тесЕ1опЕхеепз1оп$ 
{ 
рУБ11с зфаЕ1с РегпапепЕВе@1 кесеТовоиЕеКези1е АзМоуедРегтапеп1у 
(615 Вед1кесЕТовочеевези1Е гед1кесе1оп) 
{ 
тегагп пем РегтапепВед1гесЕТовоитевези1+ (гед1кгесе1оп) ; 
} 
рую11с с1азз РегтапепЕВед1хесеТовочееВези1Е : АсЕ1опВези1Е 
{ 
риБ11с Вед1кесеТоВои®евези1Е Вед1тесЕ1оп { деё; рг1фуаце зек; } 
риу611с РехмаперВед1кесеТоВочеевези1 + (ВеЯ1кесеТовоцкевези1е гед1 тес оп} 
{ 
{515 .Вед1кесЕ1оп = гед1кесЕ1оп; 
} 
руЮ11с оуегк14е уо1а Ехеситевезио1 (Сопехо11ехСопеехЕ сопеехЕ) 
{ 
// После установки нормального перенаправления переключите его на 301 
ВеЯ1гесЕ1оп .Ехесифевези1 + (сопфех®) ; 
сопфехе. НЕЕрСопЕех® .Кезропзе .ЗфафазСо4е = 301; 


} 


После импортирования пространства имен этого класса можно просто добавлять 
.АзЗМоуеЧРегиапепЕ1у() в конец любого перенаправления: 


рую11с АСЕ1опВези1Е МуАсЕ1опгМеевоа () 
{ 


хебогл ВедтхесеТоАсЕ1ол ("АпоЕрегАсЕ1оп") .АзМоуеЯРехтапепЕ1у(); 


Поисковая оптимизация 


Выше мы рассмотрели схему ОЕ]. в терминах повышения удобства и соответствия 
соглашениям НТТР. Теперь давайте посмотрим, как с помощью схемы ОБТ, можно повы- 
сить рейтинги страниц в поисковых системах. 

Ниже перечислены некоторые приемы, позволяющие увеличить шансы на получе- 
ние высокого рейтинга. 


® Используйте в ОВГ. релевантные ключевые слова: /ргобисез /дуА/зпарзопз по- 
лучит больший рейтинг чем /ргодис%з/293484. 


® Как было сказано ранее, сводите к минимуму применение параметров строки за- 
проса и не используйте подчеркивания в качестве разделителей слов. То и другое 
может повлиять на резульгат работы поисковых систем. 


® Назначайте каждой части содержимого один ОБТ, — его канонический ИБЕ. 
Рейтинги Сообе в значительной мере определяются внутренними ссылками, ве- 
дущими на единственный элемент индекса, поэтому если вы допускаете индекса- 
цию одного и того же содержимого под множеством ОВ, то рискуете “распылить” 
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рейтинг входящих ссылок между ними. Намного лучше иметь единый элемент ин- 
дексации с высоким рейтингом, чем несколько с низким рейтингом. 


Если необходимо отображать одно и то же содержимое по многим ОЧ, (например, 
чтобы не разрушить старые ссылки), перенаправляйте посетителей со старых 
ОВ! на новый канонический ОВ! через переадресацию НТТР 301 (перемещено 
постоянно). 


® Очевидно, что содержимое должно быть адресуемым, иначе оно вообще не будет 
индексироваться. Это значит, что содержимое должно быть доступно через за- 
прос СЕТ и не зависеть от запроса РОЗТ или любого рода навигации на основе 
Чауазсирь, НазВ или ЭПуег 5. 


Поисковая оптимизация (5ЕО) — темное и загадочное искусство, потому что Соое 
(м другие поисковые системы, если они еще кого-то интересуют) никогда не раскро- 
ет внутренних деталей своих алгоритмов определения рейтинга. Схема ОВГ, — только 
часть этого, а более важными аспектами является размещение ссылок и получение вхо- 
дящих ссылок с других популярных сайтов. Сосредоточьгесь на том. чтобы ОВ! лучше 
работали для людей, и тогда они также будут лучше оценены поисковыми системами. 


Резюме 


В этой главе вы ближе познакомились с системой маритрутизации, узнав, как ее ис- 
пользовать, и как она устроена внутри. Теперь вы сумеете реализовать почти любую 
схему ОВ! создавая более дружественные к человеку и оптимизированные для поиска 
ОВ и не прибегая при этом к жесткому кодированию ОК. где-либо в приложении. 

В следующей главе мы рассмотрим сердце платформы МУС Егате\могК — контрол- 
леры и действия. 


ГЛАВА 9 


Контроллеры 
и действия 


сякий раз, когда в приложение АЗРМЕТ МУС поступает запрос, его обрабатывает 

контроллер. Контроллер играет главенствующую роль, те. он может делать все, 
что угодно, для обработки запроса. Он может издать любой набор команд, адресуя их 
лежащему ниже уровню модели или базе данных. и он может визуализировать любой 
птаблон представления, вернув его обратно посетителю. Это класс С#, в который поме- 
щается любая логика, необходимая для обработки запроса. 

В этой главе вы получите детальные сведения о том, как работают эти составные 
части МУС Егате\могК, и какие возможности это открывает. Мы начнем с краткого об- 
суждения важнейнтих архитектурных принципов, а затем рассмотрим возможные вари- 
анты приема входных данных, генерации выходных данных и внедрения дополнитель- 
ной логики. Затем вы увидите, как настраивать механизмы обнаружения и создания 
экземпляров контроллеров. а также вызывать их методы. И, наконец, будет показано. 
как все эти проектные решения сочетаются с модульным тестированием. 


Краткий обзор 


Давайте вспомним. какую роль играют контроллеры в архитектуре МУС. Основная 
задача МУС — сохранять вещи простыми и организованными за счет разделения от- 
ветственности. В частности, архитектура МУС нацелена на разделение трех основных 
видов ответственности: 


® бизнес-логика или логика предметной области и хранилище данных (модель}; 
® логика приложения (контроллер); 
® логика презентации (представление). 


Такая организация выбрана потому, что она очень хорошо подходит для большинст- 
ва бизнес-приложений, которые ежедневно приходится строить разработчикам. 

Контроллеры отвечают за логику приложения, которая включает пользовательский 
ввод, генерацию команд для модели предметной области, извлечение данных из моде- 
ли, а также перемещение пользователя между различными частями пользовательского 
интерфейса. Контроллеры можно воспринимать как мост между “Всемирной паутиной” 
и моделью предметной области, поскольку основная цель приложения — позволить ко- 
нечному пользователю взаимодействовать с этой моделью. 

Логика модели предметной области — это процессы и правила, представляющие 
бизнес-деятельность. Она относится к отдельной ответственности, поэтому ее не следу- 
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ет смешивать с контроллерами. Если же это сделать, будет утрачен контроль над тем, 
какой код предназначен для моделирования объективной реальности вазтего бизнеса, а 
какой относится к проектным решениям разрабатываемого веб-приложения. В неболь- 
шом приложении на такие вещи можно не обращать внимания, но по мере возрастания 
сложности разделение ответственности становится ключевым условием успеха. 


Сравнение с АЗР.МЕТ Ме Рогт$ 


Между контроллерами АЗРМЕТ МУС и страницами АЗРХ традиционной платформы 
М/’еБЕогил$ имеется некоторое сходство. Например, те и другие являются местом взаимо- 
действия с конечным пользователем, а также содержат в себе логику приложения. Во 
всем остальном они концептуально отличаются. 


® Страницу АЗРХ УеБЕогтл$ нельзя отделить от ее класса отделенного кода, пото- 
му что только совместно они реализуют прикладную и презентационную логику 
(например, во время привязки данных), отвечая за каждую кнопку и метку на 
странице. С другой стороны, контроллеры АЗРМЕТ МУС четко отделены от лю- 
бого конкретного пользовательского интерфейса (те. представления) и являются 
абстрактным представлением набора пользовательских взаимодействий, просто 
удерживая в себе логику приложения. Такая абстракция помогает сохранять код 
контроллера простым, а это позволяет легче понять логику приложения и протес- 
тировать ее в изоляции. 


® Страницы АЗРХ УеБЕогта$ (вместе с их классами отделенного кода) имеют ассо- 
циацию “один к одному” с определенным экраном пользовательского интерфейса. 
В АЗРМЕТ МУС контроллер не привязан к определенному представлению, поэтому 
он может обрабатывать запросы, возвращая один или несколько разных пользо- 
вательских интерфейсов в зависимости от требований логики приложения. 


Естественно, реальную проверку платформа МУС ЕгатемогК проходит при построе- 
нии качественного программного обеспечения. Давайте теперь посмотрим, как реали- 
зовать и использовать контроллеры. 


Все контроллеры реализуют интерфейс тСопЕго11ехк 


В АЗРМЕТ МУС контроллеры представляют собой классы С#. Единственное требо- 
вание, которое к ним предъявляется. состоит в том, что они должны реализовывать 
интерфейс ТСопего11ек. Тут не о чем особенно говорить; ниже приведено полное оп- 
ределение этого интерфейса: 


риБ11с 1птехгГасе ТСопеко11ек 


{ 


\01а Ехесиее (ВедцезЕСопфехЕ гедиезЕСопфех®); 
} 


Таким образом, простейптий контроллер “НеПо, мойа!” выглядит следующим 
образом: 


рч611с с1азз Не11ойок1ЯСопЕко11ек : ТСопетго11ек 
{ 


руБ11с уо1а Ехесите (ВедаезЕСопеехЕ хеаиезСопеехе) 


{ 
геаиез{СопфехЕе . НеЕрСопеехе .Везропзе.Иг1фе ("Не11о, мок1а!"); 
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Если конфигурация маршрутизации включает элемент Вои®е по умолчанию (те. со- 
ответствующий шаблону {сопЕко11ет} / {ас®1оп}/ {19}), то для вызова этого контрол- 
лера нужно запустить приложение (нажав <ЁР5>) и перейти по адресу /Не11омох1а, как 
показано на рис. 9.1. 


Рис. 9.1. Вывод контроллера Не1 1оМох19Сопего11ех 


Результат не особо впечатляет, но, понятно, что в метод Ехесиее () можно поместить 
любую прикладную логику. 


Базовый класс Сопёго11ег 


На практике очень редко приходится реализовывать ТСопЕго11ег непосредствен- 
но или писать метод Ехеси+е (). Причина в том, что МУС Егате\могК поставляется со 
стандартным базовым классом для контроллеров Зузеем.Мер .Мус .Сопеко11ех, кото- 
рый реализует ТСопЕхо11ех. Он намного мощнее чистого интерфейса тТСопЕго11ех и 
предоставляет следующие возможности. 


® Методы действий. Поведение контроллера разделено на множество методов (вме- 
сто единственного метода Ехесиее ()). Каждый метод действия виден внешнему 
миру через свой ОВГ, и вызывается с параметрами, извлекаемыми из входящего 


запроса. 


» Результаты действий. Из метода можно вернуть объект, описывающий желае- 
мый резульгат действия (например, визуализацию представления, переадресацию 
на другой ОРГ. или другой метод действия), который затем выполняется автомати- 
чески. Благодаря отделению определения результатов от их выполнения, сущест- 
венно упрощается автоматизированное тестирование. 


® Фильтры. Многократно используемое поведение (например, аутентификация или 
кэширование вывода) можно инкапсулировать в виде фильтров. после чего с по- 
мощью [АсЕх1риЕе] пометить каждый из них в одном или более контроллерах 
или методах действий. 


Все эти средства подробно рассматриваются в настоящей главе. В предыдущих гла- 
вах вы уже видели в действии немало контроллеров и методов действий, но для иллю- 
страции сказанного выше приведем еще один пример: 


[ОцЕерчеСасВе (РигаЕ1оп=600, УагуВуРагкап="*") ] 
руБ11с с1азз БепоСопеко11ех : Сопего11ег 
{ 
риБ11с УтемВезо1Е ЗроисгееЕ1тч () 
{ 
У1емраба["СкееЕ1та"] = "Не11о, мок1а!"; 
хебики Утем ("Му\У1ем") ; 


258 часть И. АЗР.МЕТ МУС во всех деталях 


Этот простой класс контроллера РетосопЕхо11ет использует три средства, которые 
упоминались ранее. 


® Поскольку он унаследован от стандартного базового класса Сопего11ех, все его 
общедоступные методы являются методами действий и потому могут быть вы- 
званы из Веб. ОВ. каждого метода действия определяется активной конфигура- 
цией маршрутизации. При конфигурации по умолчанию метод ЗпозСтеее1 па () 
можно вызывать, запрашивая /Репо/5$БоиСгеее1п9д. 


® ЗпомСгееЕ1тоа() генерирует и возвращает объект результата действия, вы- 
зывая У1еи (). Этот конкретный объект У1емВези1е инструктирует платфор- 
му о том, что нужно визуализировать шаблон представления, находящийся в 
/У1еиз/Репо/Му\У1еи.азрх, и снабдить его данными из коллекции У1еиПаса. 
Представление объединяет эти значения в своем шаблоне, производя и доставляя 
готовую НТМЕ-страницу. 


® Имеется атрибут фильгра [ОцёраЕСасве], который кэширует и повторно исполь- 
зует вывод контроллера в течение определенного периода времени (в данном при- 
мере 600 секунд, те. 10 минут). Поскольку атрибут присоединен к самому классу 
РетоСопЕтго11ек, он применяется ко всем методам действий Ретобопеко11ехг. 
В качестве альгернативы фильгры можно присоединять к индивидуальным мето- 
дам действий, как будет показано далее в этой главе. 


На заметку! Если щелкнуть правой кнопкой мыши на имени проекта или папке /СопЕхо11етз 
и выбрать в контекстном меню пункт Ада= Сощгойег (Добавить=>Контроллер), Мзиа! Знаю 
автоматически создаст класс контроллера, унаследовав его от базового класса Зузсет.Иеь. 
Мус.Сопего1Тек. При желании это можно сделать и вручную. 


Как и во многих технологиях программирования, код контроллера следует следую- 
щему базовому шаблону: ввод=>обработка= вывод. Далее в главе рассматриваются воз- 
можные варианты ввода данных, обработки и управления состоянием и отправки вы- 
вода в веб-браузер. 


Получение вводимых данных 


Контроллерам часто нужно иметь доступ к входным данным. таким как значения 
строки запроса, значения формы и параметры, извлеченные из входящего ОЕ! систе- 
мой маршрутизации. Существуют три основных способа доступа к таким данным. Их 
можно извлечь из набора объектов контекста, передать данные как параметры в ме- 
тод действия или непосредственно вызывать средство привязки модели. Рассмотрим 
все приемы по очереди. 


Получение данных из объектов контекста 


Наиболее прямой путь для получения входных данных состоит в извлечении их вруч- 
ную. Если контроллер унаследован от базового класса Сопего11етк платформы, с по- 
мощью таких его свойств, как Ведиез+, Везропзе, Вочкерака, НЕЕрСоптехе и 5егуег, 
можно получать доступ к значениям СЕТ и РОЗТ, заголовкам НТТВ, информации соо 1е- 
наборов и ко всему прочему, что МУС известно о запросе". Метод действия может извле- 
кать данные из многих источников, например: 


1 Все эти свойства являются просто сокращениями для доступа к полям свойства Сопско11етСопсехс. 
Например, КедиезЕ — это эквивалент СопЕго11егСопфехе .НЕЕрСопеех .Ведиез-. 


рУБ11с Асе1топВези1е ВепапеРгодисе () 


{ 
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// Доступ к различным свойствам объектов контекста 
зЕг1п9 изегМаме = Озег. ТаепЕ1у .Мапе; 


зЕг1п9 зегхуегМаще = Зегуег .МасЬ1пеНнапе; 


зЕгтипа стлепЕТР = Ведаез®.ОзегНозЕАЧагезз; 
РафеТ1ме дабебЕатр = НЕЕрСопеехе. Т1мезвапр; 
АиЯ1ТЕВесдлезе (азегМате, зегуехМате, с11епЕТР, дабебфапр, "Вепаплпа ркодисе") ; 


// Извлечь отправленные данные из ВеадаезЕ .Еогт 

зЕг1па о1ЯРгодосЕМаще = Весаез®.Гоги["О1ЯМаще"]; 

зЕг1па пеиРгодасЕМаше = Веадаез®е.ЕКоги["МемМапе"]; 

Боо1 геза1Е = АббетрЕРкодас®Вепапе (о1ЯРкодисЕМаще, пемРкодас® Мате); 
У1еибака ["ВКепапевез01%"] = гезо1; 
хебакпр Улем ("РХОЗИСЕВепатей") ; 


} 


Наиболее часто используемые свойства объектов контекста перечислены в табл. 9.1. 


Таблица 9.1. Часто используемые свойства объектов контекста 


Свойство Тип Описание 

Вечцез* .Оцегу5г1па Мапеуа]еСо11 ес 1оп Переменные СЕТ, отправленные в запросе. 

Ведлез®.Рогт МамеУаТаеСо1ес1оп Переменные РОЗТ, отправленные в запросе. 

Вечцезе .Соок1ез НЕсрСоок1еСо1ес1оп СооКе-наборы, отправленные браузером в 
данном запросе. 

Вечцез® .НЕЕрМесвов зЕЕ1п9 Метод НТТР (слово СЕТ или РОЗТ), исполь- 
зуемый в данном запросе. 

Ведиез* .НеаЯегз МапеУа]меСо11ес+1оп Полный набор заголовков НТТР отправлен- 
ных в запросе. 

Вечиезе. 0х1 0х1 Запрошенный ЦВЕ. 

Ведлезе.ОзегНозЕАЯЯгезз эта |Р-адрес пользователя, выполнившего запрос. 

Вонкерафа.ВКоифе КопфсеВазе 


Боперафа .Уа1ез 


НЕЕрСопЕех® .Арр]1са*1оп 


ВоофеУа]пер лс 1опагу 


НЕБрАрр11са 1 оп асеВазе 


Выбранный элемент Воотетаю1е.вВопеез 
для данного запроса. 


Активные параметры маршрута (извлечен- 
ные из УВЕ или принятые по умолчанию). 


Хранилище состояния приложения. 


НЕ фрсопжех® .Сасве Сасве Хранилище кэша приложения. 

НЕбрСопеех® .Теетз Трас®1опагу Хранилище состояния текущего запроса. 

НЕЕрСопеех®.5е35100 НЕбрбеззтопафеВазе Хранилище состояния сеанса посетителя. 

Озег ТРЕ псфра1 Информация об аутентификации о текущем 
пользователе. 

Тетрраса Тепррафар1с1опагу Элементы данных, сохраненные при обра- 


ботке предыдущего запроса НТТР в данном 
сеансе (подробнее об этом позже). 


Все доступные сведения о контексте запроса можно просмотреть с помощью сред- 


ства ПчеШ$Зепзе (введите 613. в методе действия и просмотрите раскрывающийся 
список) или в документации МОМ (найдите справочную информацию по Зузфепт.Меь. 
Мус .Сопего11ет или Зузбеп.Меь.Мус .СопЕго11ехСопеех+). 
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Использование параметров методов действий 


Как было показано в предыдущих главах, методы действий могут принимать пара- 
метры. Зачастую это более аккуратный способ получения входных данных, чем ручное 
их извлечение из объектов контекста. Если удастся сделать метод действия чистым?, 
те. зависимым только от его параметров и не затрагивающим данные контекста, будет 
легче понять его логику и реализовать модульное тестирование. 

Например, вместо написания следующего кода: 


рур11с АсЕ1орВези1Е ЗпомМеа ВекЕогкесаз® () 

{ 
зЕк1па с1Ёу = Воцберафа .Уа1аез["с1еу"]; 
РафсеТ1тше Еокрафе = БаееТ1те .Рагзе (Ведчиезе . Гоги ["ЁЕограее"]); 
// .-. реализовать прогноз погоды ... 


} 
можно записать такой код: 


рУБ11с АсетопВезо1Е ЗромМеаеветГогесаз® (3%х1п9 с1еу, РафеТаме Еохрафе) 
{ 
// .-- реализовать прогноз погоды ... 


} 


Для подстановки значений в параметры МУС Егате\хогК сканирует несколько объек- 
тов контекста, включая Веаиез&.Оцекгу5Ет1па, ВКедаезе .Еогм и Вочберака .Уа1иез, в 
поисках соответствия пар “ключ/значение”. Ключи нечувствительны к регистру симво- 
лов, поэтому параметр с1%у может быть получить значение из Ведаезе .Еоги["С1еу"]. 
(Как вы должны помнить, КоифеЛака .У\а1иез — это набор параметров в фигурных скоб- 
ках, извлеченных системой маршрутизации из входящего ОВГ, плюс любые параметры 
маршрута по умолчанию.) 


Создание объектов параметров с помощью 
средства привязки модели 


“За кулисами” существует компонент СопЕго11егАсЕ1опТиуокехг, который в дейст- 
вительности вызывает метод действия и передает ему параметры. Значения парамет- 
ров он получает с использованием другого средства платформы, называемого привязкой 
модели. 

Далее вы убедитесь, что привязка модели может поставлять объекты любого типа 
„МЕТ, включая коллекции и собственные специальные типы. Например, это означает 
возможность получения загруженного (на сайт) файла просто путем добавления к мето- 
ду действия параметра типа НЕЕрРозеедЕ11еВазе. Пример такого подхода был приве- 
ден в конце главы 6 при реализации административной функции загрузки изображений 
товаров в приложении Эройз юге. 

Особенности работы привязки модели, включая назначение приоритетов для раз- 
личных объектов контекста, синтаксический разбор входящих строковых значений в 
произвольные типы объектов .МЕТ, а также рекурсивное заполнение целых коллекций и 
графов объектов рассматриваются в главе 11. Дополнительные сведения о компоненте 
Сопего11ехАсЕ1опТпуокег и его настройке предлагаются далее в этой главе. 


2 Это понятие хотя и близкое, не совсем тождественно чистой функции в теории функцио- 
нального программирования. 
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Обязательные и необязательные параметры 


Если компонент Сорего11егАсЕ1опТруокКег не может найти соответствие для опре- 
деленного параметра, он пытается передать в качестве его значения по11. Это годит- 
ся для ссылочных типов и типов, допускающих значение по11 (наподобие зЕх1п9), но 
для типов значений (таких как 10% или расеТ1ме) будет сгенерировано исключение$. 
Давайте рассмотрим это с другой точки зрения. 


® Параметры типов значений по своей природе являются обязательными. Чтобы 
сделать их необязательными, для них необходимо указывать типы, допускающие 
значение по11 (вроде 10е? или РафеТ1пе?). В этом случае платформа сможет пе- 
редавать по11, если нет доступного значения. 


® Параметры ссылочных типов по своей природе являются необязательными. Чтобы 
сделать их обязательными (те. гарантировать, что в них не будет передаваться 
значение по11), в начало метода действия потребуется добавить некоторый код, 
который будет отклонять значения по11. Например. если значение равно по11, 
он может сгенерировать исключение АгоаиепЕМо11ЕхсерЕ1оп. 


Здесь не идет речь о проверке достоверности введенных данных в пользовательском ин- 
терфейсе: о том, как реализовать для конечного пользователя напоминания о необходимости 
заполнения обязательных полей, читайте в разделе “Проверка достоверности” главы 11. 


Параметры, которые привязать нельзя 


Для полноты картины стоит упомянуть, что методы действий не могут иметь пара- 
метров опЕ или геЕ. Если бы могли, то это не имело бы смысла. АЗРМЕТ МУС просто 
генерирует исключение, когда встречает такой параметр. 


Ручной вызов привязки модели в методе действия 


В сценариях с вводом данных нередко предусматривается форма <Еогш> с отдель- 
ными полями для каждого свойства объекта модели. При приеме отправленных данных 
можно копировать каждое входящее значение в соответствующее свойство объекта, 
например: 


руЮ11с Асёлопвезы1Е бобпы ЕЕЯ1ЕеаРкоачсе® () 
{ 
РГоансЕ ргоаисЕ = фоаАРгоаосЕВУТО (1п®.Рагзе (Кечиез® .ЕГоги ["РгоассЕтр"])); 
ргодасе.Маше = Кедаез®.Еоги ["Маше"]; 
ргодасе.Резсутрётопт = Кечаезе.Еоги ["Резсу1рЕ1опт"]; 
ркодасЕ.Ри1се = досБ1е .Рагзе (ВКеааез®.Еохи["Ру1се"]); 
Соши1 ЕСВапдез (ргоЧчцс®) ; 
тегагп ВеЯ1гесЕТоАсЕтоп ("Т1$Е"); 


} 


Болыная часть этого кода тривиальна и предсказуема. К счастью, помимо использо- 
вания привязки модели для получения целиком заполненных объектов как параметров 
методов действий, привязку можно вызывать явно для обновления свойств любого уже 
созданного объекта модели. 


ЗВ С# классы относятся к ссылочным типам (хранящимся в куче), а структуры — к типам 
значений (расположенным в стеке). Наиболее часто используемыми типами значений явля- 
ются 116, Боо1 и РасаТлие (однако обратите внимание, что зЕг1па — это ссылочный тип). 
Ссылочные типы могут принимать значение по11 (дескриптор объекта устанавливается в 
состояние, означающее “нет объекта”), а типы значений — нет (с ними не связан дескрип- 
тор; зто просто блок памяти, используемый для хранения значения объекта). 
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Например, предыдущий метод действия можно упростить следующим образом: 


ру611с АсЕ1топВезы1е Зиби1ЕЕа1ееаРхоачсь (1пе рхоЯнсетр) 
{ 
РкоЯисе ргоацсе = ГоааРхоанс&ВуТр (рхо@ачсЕ То); 
ОрааЕеМмо@е1 (рхо@ос+) ; 
Соти1 ЕСВапдез (ргоансе) ; 
теги ВеЯ1гесеТоАсе1от ("1156"); 
} 


В завершение дискуссии сравните этот код с приведенным ниже. Он почти такой 
же, но использует привязку модели неявно. 


РУБ11с Асё1опВези1 бан: ЕЕА1Ееарго@ась (РкодасЕ рго@ис®) 
{ 

Сопи1тЕСвапдез (рходис®); 

хегоги ВеЯд1кес®ТоАсетоп ("115%"); 


} 


Неявная привязка модели обычно позволяет создать более ясный и читабельный 
код. Однако явная привязка модели обеспечивает более полный контроль над началь- 
ным созданием экземпляров объектов. 


Генерация вывода 


После того, как контроллер получил запрос и обработал его некоторым образом (обыч- 
но подключая уровень модели), ему нужно сгенерировать некоторый вывод для пользова- 
теля. Различают три основных типа ответов, которые может произвести контроллер. 


1. Он может вернуть НТМГ-разметку, визуализируя представление. 
2. Он может выполнить перенаправление НТТР (часто на другой метод действия). 


3. Он может записать некоторые данные в выходной поток ответа (возможно, тексто- 
вые данные вроде ХМГ. или УЗОМ или двоичные данные с помещением их в файл). 


Далее в главе будет будут даны описания каждого из перечисленных вариантов. 


Концепция АсЕ1опВези1 Е 


В случае создания совершенно нового класса, реализующего интерфейс тСопЕхко11 ег (те. 
напрямую реализуя ТСопЕго11ег, а не наследуя класс от ЗузЕет.Меь .Мус .Сопего11ехт), 
сгенерировать ответ можно любым подходящим способом, непосредственно взаимо- 
действуя с сопЕго11егСопеехе .НЕЕрСопеех* .Везропзе. Например, можно передать 
НАМЕ-разметку или выполнить перенаправление НТТР: 


руБ11с с1аз5 ВагеМера1Сопеко11ег : ТСопеЕго1Тег 
{ 
ручб11с уо1а Ехесиее (Кечиез®СоптехЕ геаицезеСопееху) 
{ 
хедиезСопеехе. НЕЕрСопфехе. Везропзе.Их1 фе ("Т <5>1оуе</ь> НТмь!"); 
//... или... 
хедиезЕСопфехе. НЕЕрСопфехЕ.Везропзе .ВеЯ1 тес ("/Зоте/ОНек/0х1"); 


} 


Подход прост и он работает. То же самое можно было бы делать и с контроллерами, 
унаследованными от класса Сопего11ех, напрямую обращаясь к свойству Везропзе: 
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рУБ11с с1аз$ бипр1еСопЕко11ег : Сопего11ек 
{ 
риЮ11с \о01а МуАсЕ1опМеевоа () 
{ 
Везропзе.ИхгтЕе("Т'11 пеуех зфор аз1па Ее <511оКк>Ь1так</Ь110К> Еад"); 


И 
Кезропзе .ВеЯ1гесе® (" /Зоте/ОЕНех/0х1"); 
// ... или... 


Везропзе.Тхапзи1 Е11е (@"с: \Е11ез\зомеЕ11е.21р"); 


} 


Это также работает, и так можно поступать“, но такой подход чреват неудобствами 
при модульном тестировании. Коду требуется работающая реализация Везропзе (объ- 
ект НЕЕрВезропзеВазе), поэтому придется либо создать тестовый дубль. либо реализо- 
вать соответствующую имитацию. В любом случае тестируемый объект должен как-то 
записывать, какие вызовы методов и какие параметры он получал, чтобы тест мог про- 
верить, что произошло. 

Чтобы обойти это неудобство, в МУС установка намерений отделяется от выполне- 
ния этих намерений. Ниже описано, как это делается. 


® Метод действия избегает прямой работы с Везропзе (хотя иногда может не быть 
выбора). Вместо этого он возвращает объект, унаследованный от базового класса 
АсЕ1опВези1*, который описывает ваши намерения относительно того. какого 
рода ответ нужен (например, визуализировать конкретное представление или пе- 
ренаправить на определенный метод действия). Модульные тесты могут просто 
проинспектировать объект результата действия, чтобы убедиться, что он описы- 
вает необходимое поведение. Примеры модульного тестирования будут приведены 
далее в этой главе. 


® Все объекты Асе1опВези1 имеют метод по имени Ехесотевези1* (); фактически 
это единственный метод базового класса Асе1опВезо1*. Во время работы при- 
ложения этот метод вызывается и действительно выполняет назначенный ответ, 
непосредственно взаимодействуя с Везропзе. 


Тестируемость является основным преимуществом применения результатов дей- 
ствий. Другим преимуществом считается аккуратность и простота их использования. 
Дело не только в наличии компактного АР!-интерфейса для генерации типичных объек- 
тов АсЕ1опВези1* (же. визуализации представления), но еще и в возможности создания 
специальных подклассов АсЕ1опКезо1+ для упрощения многократного использования 
(и тестирования) новых шаблонов ответа во всем приложении. 


На заметку! В контексте шаблонов проектирования это относится к шаблону Соттапа (команда). 


В табл. 9.2 перечислены встроенные типы результатов действий. Все они являются 
подклассами АсЕ1опВезо1+. 

Далее будет показано, как использовать каждый тип результата. а также предложен 
пример создания собственного специального типа АсЕ1опВеза1е. 


я Разумеется, отобразить НТМГ-разметку, выполнить перенаправление НТТР и передать дво- 
ичный файл в одном и том же ответе НТТР нельзя. Эти операции можно производить толь- 
ко по одной на ответ, что является еще одной причиной, почему семантически чище вернуть 
АсЕтопВезо1%, чем выполнять последовательности операций непосредственно с Везропзе. 
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Таблица 9.2. Встроенные типы АсЕ1опВези1 в АЗР.МЕТ МУС 


Тип результирующего объекта 


Назначение 


УтеиВези1е 


РагЕ1а1У1лемВези1& 


Веа1кесеТовоцеевези1е 


Веа1гесеВези1 


СоптепЕВези1 


Е11евези1е 


9зопВези1е 


Чауа5сг1рЕВези1е 


НЕЕрУпаи Вок1теаВези1& 


ЕПреуВе5и1е 


Визуализирует назначенный или ус- 
тановленный по умолчанию шаблон 
представления. 


Визуализирует назначенный или ус- 
тановленный по умолчанию шаблон 
частичного представления. 


Издает перенаправление НТТР 302 
на метод действия или определенный 
элемент маршрута, генерируя УВЕ 
согласно активной конфигурации 
маршрутизации. 


Издает перенаправление НТТР 302 
на произвольный ЦВЕ. 


Возвращает неформатированные 
текстовые данные в браузер, допол- 
нительно устанавливая заголовок 
сопфепе-Фуре. 


Передает двоичные данные (такие как 
файл с диска или байтовый массив из 
памяти) непосредственно в браузер. 


Сериализует объект .МЕТ в формате 
ОМ и отправляет его как ответ. 


Отправляет фрагмент исходного кода 
чамазсирь, который должен быть вы- 
полнен браузером. Это предназначено 
только для сценариев Арх. 


Устанавливает код состояния 
НТТР-ответа в 401 (означает “не 
авторизовано”), что заставляет ак- 
тивный механизм аутентификации 
(Рогтз АшИепёсайоп или \Мпдо\ 
Аиепёсаноп) предложить посетителю 
войти в систему. 


Ничего не делает. 


Пример использования 


хебоки У1лем(); 
тебаги Улем ("Му\У1ем", 
поае10)ес®); 


тебаги Рагё1а1Улем(}; 

тебоги Рах1а1\У1ем ( 
"МуРаг&1а1", 
поде10Ю]есЕ); 


Верагп 
КеблкесТоАсётоп ( 
"бопеоспекАсЕлот", 
"зопеСопето11ех"); 
тегигп 
Веа1кесеТовоцте ( 
"МУМапедвонте"}; 


теракт 
Вед1кес® ( 
"ВЕЕр: //иии-ехатр1е. сом"); 


хебакп Сопбепф (5555 х1па, 
"арр11сае1оп/хз$+хи1"); 


тегоги Е11е( 
@"с:\героге.раЕ", 
"арр11са1оп/раг"); 


хегиги 9зоп (5ошеОБесе}; 


хебикй 
Зауа$ск1ре ( 
"$ (#+туе1епепе) .в1ае (};"); 


хебоги пеи 
НЕЕрОпачеВог1хеЯВези1* ()}; 


тебако пем ЕиреуВези1{ (); 


Возврат НТМЕ-разметки с помощью 
визуализации представления 


Большинство методов действий предназначено для возврата браузеру некоторой 
НТМГ-разметки. Для этого визуализируется шаблон представления, что означает воз- 
врат резульгата действия типа У1еиВези1%, например: 
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ру611с с1азз Аат1пСопего11ех : СопЕко1Тег 
{ 
рур11с У1емВезу1Е Тпдех () 
{ 
тесаги Улем ("Нопераде"); 
// Этот оператор равнозначен следующему: 
// гекаги пем УземВезы1® { УлемМате = "Нопераде" }; 


На заметку! В частности, в приведенном выше методе действия объявлено, что он возвращает 
экземпляр \1еиВези1 +. Метод бы работал точно так же, если бы вместо этого возвращал тип 
Асе1опВези1+ (базовый класс для всех результатов действий). Действительно, некоторые 
разработчики веб-приложений АЗР.МЕТ МУС объявляют все свои методы действий как возвра- 
щающие неспецифический АсЕтопвезо1 +, даже если точно знают, что методы всегда будут 
возвращать определенный его подкласс. Однако необходимость возврата методами наиболее 
специфичного типа из числа возможных (равно как выбор наиболее общих типов для парамет- 
ров) — это устоявшийся принцип объектно-ориентированного программирования. Следуя это- 
му принципу, можно достичь максимального удобства и гибкости кода, который будет вызывать 
метод (например, код модульных тестов). 


Вызов метода У1еи() привод к генерации объекта У1емкезо1 +. Во время выполне- 
ния У} еивези1е встроенный механизм представлений МУС — МергогтУ1емЕ поте — 
по умолчанию будет искать шаблон представления в следующих местах (в указанном 
порядке}: 

1. //леиз/Сопего11егМапе /У1еи"Маще .азрх 

2. /МУ1еиз/СопЕго11егМаме/У1еиКаме.азсх 

3. /МЛеиз/5Багеа/У1е Мате .азрх 


4. /леиз/5$вагеа/УтеиМацще .азсх 


На заметку! Дополнительные сведения касательно реализации этого соглашения об именовании и 


его настройки ищите в разделе “Реализация специального механизма представлений” главы 10. 


Итак, в этом примере вначале просматривается /У1еиз /{ АЧ9и1о/номераде.азрх 
(обратите внимание, что, согласно соглашению об именах контроллеров. суффикс 
Соп+го11ег из имени класса контроллера исключен). Сделав еще один шаг в сторону 
подхода “преимущество соглашения над конфигурацией”, можно вообще опустить имя 
представления, например: 


роь11с сТтазз Ааш1иСопего]Лег : СопегоЛег 


{ 
рую11с У1емВези1е Тпаех () 


{ 
тесаго У1ем (); 
// Этот оператор равнозначен следующему: 
// хетакп пем УтемВезо1е (); 


} 


В таком случае будет использоваться имя текушего метода действия (оно определено 
в Воиберафа .Уа1щез ["ас+1оп"1), поэтому в данном примере первое место, где произво- 
дится поиск шаблона представления — это /\1емз/Адт1и/Тпаех.азрх. 
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Доступно еще несколько других переопределений метода контроллера У4еи (); все они 
соответствуют установкам различных свойств результирующего объекта УтеиВези1+. 
Например, можно указать явное имя мастер-страницы или явный экземпляр Т\У1ем (это 
обсуждается в следующей главе). 


Визуализация представления по заданному пути 


Выше было показано, как визуализировать представление в соответствии с соглаге- 
ниями об именовании и структуре папок АЗРМЕТ МУС. Однако эти соглашения можно 
обойти и явно указать путь к определенному шаблону представления, например: 


РУБ11с с1а55 Ади1ипСопЕко11ег : Сопего11ег 
ру611с УлемВези1е Тпаех (} 

хебако Узем ("^/раеВ/фо/ зоме/у1еи.азрх"); 
} 


Обратите внимание, что полные пути должны начинаться с / или -/ и включать 
расптирение имени файла (обычно -.азрх). Если только не зарегистрирован специаль- 
ный механизм представлений, файл, на который производится ссылка, должен быть 
страницей представления АЗРХ. 


Передача словаря У1енрака и объекта модели 


Как вам известно, контроллеры и представления — это совершенно разные, неза- 
висимые вещи. В отличие от традиционной платформы АЗРМЕТ \МеБЕогтаз, где логика 
отделенного кода глубоко переплетена с разметкой А$РХ, в МУС стимулируется разде- 
ление прикладной и презентационной логики. Контроллеры поставляют данные своим 
представлениям, но представления напрямую не обращаются к контроллерам. Такое 
разделение ответственности является ключевым фактором аккуратности, простоты и 
тестируемости МУС. 

Механизм передачи данных от контроллера к представлению — это У1еираха. Базовый 
класс Сопего11ег имеет свойство по имени У1еирафа типа Утеира®ар1 сЕ1опахку. 
Использование свойства Утеирафар1се1опаку уже демонстрировалось во многих пре- 
дылущих примерах, но пока не было четко показаны различные способы подготовки 
структуры У1емрака и ее получения из контроллера. Давайте рассмотрим доступные 
возможности. 


Интерпретация \7+ерафа как слабо типизированного словаря 


Первый способ работы с У1еирафа предусматривает использование семантики словаря 
&е. пар “ключ/значение”). Например, заполните структуру У1еираха следующим образом: 


рУю11с с1аз$ Регзоп 
{ 
рур11с зЕг1па Маше { дек; век; } 
рур11с 11 Аде { дее; зе®; } 
} 
рур11с У1емВези1е ЗноиРегзопОефа11$ () 
{ 


Регзоп зотедиу = пем Регзоп { Мате = "5ёеуе", Аде = 108 }; 
Узеирафа ["регзоп"] = зоместу; 

Узеирафжа ["пмеззаде"] = "Не11о"; 

тебики У1ем(); // ...или указать имя представления, 


// например: гегигп Утем ("ботематеЯУтем") ; 
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Сначала коллекция У1еирафа контроллера заполняется парами “имя/значение”, по- 
сле чего визуализируется представление. Затем коллекция У1ехПафа передается шабло- 
ну представления. в котором к ее значениям можно обращаться следующим образом: 


<%= УзлеиБафжа["пеззаде"] %>, мог1а! 


ТЬе регзоп'з пате 1$ <%= ((Регзоп) У1лембата["регзой"]) .Маме %> 
ТЬе регзоп'5 аде 15$ <%= ((Регзоп) У1емБафа["ретзоп"]) .Аде %> 


Семантика словаря является очень гибкой и удобной, так как она позволяет отправ- 
лять любую коллекцию объектов и затем извлекать их по имени. Заранее объявлять эти 
объекты не понадобится; это того же рода удобство, которое обеспечивают слабо типи- 
зированные языки программирования. 

Недостаток использования У1ехрафа в качестве слабо типизированного словаря 
состоит в том, что при написании шаблона представления отсутствует поддержка со 
стороны Н\еШ5ензе относительно выбора значений из коллекции. Необходимо точно 
знать ключи (в рассматриваемом примере это регзоп и пеззаде) и применять явные 
ручные приведения типов, если они не относятся к простейшим типам вроде зт11п9. 
Разумеется, здесь не поможет ни среда 13а! Зёааю, ни компилятор, поскольку фор- 
мальная спецификация того. какие элементы должны быть в словаре, отсутствует (это 
определяется только во время выполнения). 


Передача строго типизированного объекта в Уземрафа .Моде1 


В классе У1еирабар1сЕ1опагу определено специальное свойство по имени Моает1. 
Этому свойству можно присвоить любой объект „МЕТ, добавив в метод действия опера- 
тор У1еирафа.Моае1 = туОБЗес+; или передав шуОБ]ес® в качестве параметра методу 
Утеи (). Ниже показан пример. 


ру611с У1емВКезо1е 5БомРегзоп[ета11$ () 
{ 


Регзоп зомедоу = пем Регзоп { Маме = "5%еуе", Аде = 108 }; 
гебаги Узеи (зощесту); // Неявно присвоить ‘зотесиу’ свойству УземРафа.Моде1 
// .--или указать имя представления, например: 


// тесаги Утем (зомедчу, "ботеМмапед\У1ем"); 


} 


Теперь к свойству У1еиПафа .Моде1 можно обращаться в шаблоне представления: 


Те регзоп'3 паше 1$ <%= ( (Регзоп) Моае1) .Мате $> 
ТЬе регзоп'5 аде 13 <%= ((Регзоп) Моае1) .Аде %> 


На заметку! В шаблоне представления в качестве сокращенного способа ссылки на Утеирафа. 
мМоае1 можно использовать Моае1. Однако в методе действия должна указываться полная 
ссылка: У1еиПафа .Моае1. 


Но такой способ вряд ли можно считать усовершенствованием. Мы приносим в 
жертву гибкость передачи множества объектов в словаре, и все равно должны выпол- 
нять неуклюжие приведения типов. Реальное преимущество проявляется тогда, когда 
используется страница строго типизированного представления. 

О значении и технической реализации строго типизированных представлений пой- 
дет речь в следующей главе, а пока что предлагается только краткий обзор. После созда- 
ния нового шаблона представления (с помощью щелчка правой кнопкой мыши внутри 
метода действия и выбора в контекстном меню пункта АЧа \Ме\м (Добавить представле- 
ние) появляется возможность создать строго типизированное представление, указав тип 
объекта модели, который нужно визуализировать. Выбранный тип определяет тип свой- 
ства Моае1 представления. Если указан тип Регзоп, неуклюжие приведения типа Моае1 
больше не понадобятся, к тому же начнет действовать средство п\еНЗенее (рис. 9.2). 


268 часть |. АЗР.МЕТ МУС во всех деталях 


ВЕ Е ГИМН ЕТО кньиси > 


— 
Е 


> 


т 


ка реза 


ч ЕдыаЕ | 
зе бенНезНСове | 
3 беТуре 

„т Мате 
—# Тобаа Е 


Рис. 9.2. Данные строго типизированного представления позволяют пользоваться 
средством и\е!$епзе при редактировании шаблона представления 


Программисты С# несомненно оценят преимущества строгой типизации. Однако с 
ней связан и недостаток: возможность передачи в У1еирафа.Мо4е1 только одного объ- 
екта, что неудобно, когда необходимо отобразить несколько сообщений состояния или 
других значений вместе с объектом Регзор. Для передачи множества строго типизиро- 
ванных объектов придется создать класс-оболочку, пример которого показан ниже: 


руЮ11с с1а5$ 5вомРегзопУ1емрака 

{ 
рур11с Регзоп Регзоп { дее; зе; } 
рур11с встг1пд 5+аеи5Меззаде { деф; зес; } 
рур11с 1пЕ СигкепеРадеМитьег { деф; зе; } 


} 


После этого бвомРегзопУ1еира+ка следует установить в качестве типа модели для 
строго типизированного представления. Это неплохая стратегия, но, в конце концов, 
необходимость постоянно писать эти классы-оболочки, надоест 


Комбинация обоих подходов 


Замечательная особенность У1еПафар1сЕ1орагу состоит в том, что он позволяет 
одновременно использовать оба приема — со слабой и со строгой типизацией. Это ис- 
ключает необходимость в написании класса-оболочки. Один первичный строго типизи- 
рованный объект можно присвоить свойству Моае1, после чего добавить произвольный 
словарь других значений, например: 


рУ611с У1емВези1е ЗВоирегзопрефа113 () 
{ 
Регзоп зотедиау = пем Регзоп { Маше = "$%ете", Асе = 108 }; 
Утемрафа ["меззаде"] = "Не11о"; 
УтеиРафа ["сисхепЕРадеМоцьег"] = 6; 
хеЕагп Узеи (зотедау); // Явно присвоить зошесау свойству Уземрафа.Мо4е1 
// --.или специфицируйте имя представления, 
// например гериги У1ем (зопедцу, "ЗошеМашеду\У1еи"); 


} 
Теперь в шаблоне представления можно обращаться к ним следующим образом: 


%= У1емПаба["меззаде"] %>, могла! 
Тве регвоп'5 паше 1$ <%= Мо4е1.Маше %> 
Тре регзоп'з аде 15 <%= Моае1.Аде %> 
Уоц'ге оп раде <%= Улемраха ["сигтереРадеМианьег"] $%> 


В данном случае достигнут баланс между надежностью строгой типизации и гибко- 
стью слабой типизации. 
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Это далеко не все, что следует знать о У1еиБафар1с&1опаку. В частности, в нем пре- 
дусмотрен специфический синтаксис нахождения и форматирования элементов слова- 
ря без необходимости приведения тинов. Но это в большей степени касается представ- 
лений, чем контроллеров, поэтому оставим рассмотрение вопросов подобного рода до 
следующей главы. 


Выполнение перенаправлений 


Часто определенный метод действия вместо возврата НТМЕ-разметки должен пере- 
дать управление какому-то другому методу действий. 

Рассмотрим следующий пример: после того, как некоторый метод действия 
сауеВесока() сохранил данные в базе, необходимо отобразить экранную сетку со все- 
ми записями (для чего предусмотрен другой метод действия по имени Тпаех () }. Навы- 
бор доступны три варианта. 


» Визуализировать сетку как непосредственный результат вызова метода действия 
ЗауеБесохга (), дублируя код, который уже имеется в Тпаех (). Понятно, что это 
не самый изящный способ. 


» Вызвать метод Траех () непосредственно в ЗауеВесокга (): 


руЮ11с У1емВези1е бахевесога (1пЕ 1@, зеглоа пемМапе) 


{ 
// Получить модель предметной области для сохранения данных 
Рота1ипМо@е1 .бауе0рдаееяВесога (14, пемМапе); 
// визуализировать сетку со всеми элементами 
хебакп Тпаех(); 


} 


Несмотря на то что дублирование кода сокращается, нарушается работа несколь- 
ко других вещей. Например, если тпаех () попытается визуализировать свое пред- 
ставление по умолчанию, то он на самом деле визуализирует представление по 
умолчанию для действия бауеВесога, потому что Вочферафка. \Уа1нез$ ["асё1оп"] 
все еще равно ЗауеВесога. 


» В методе $ауеВесога () выполнить перенаправление к действию Траех (): 


руБ11с Вед1кесеТовоскевези1е Зауевесог@ (1п6 1а, зЕг1па пемМапе) 
{ 
// Получить модель предметной области для сохранения данных 
Рота пМодет .бахе0рдатейвесога (14, пемМапе); 
// Визуализировать сетку со всеми элементами 
гебагип ВеЯ1гесЕТоАсЕ1 оп ("Тпаех"); 


} 


Это вызовет перенаправление НТТР 302 к действию Тпдех (). Браузер выполнит 
совершенно новый запрос СЕТ к /Сопеко11егМате/ Тпаех, изменяя ОВТ, ото- 
бражаемый в его строке адреса. 


5 Строго говоря, в спецификации протокола НТТР указано, что для выполнения переадре- 
сации НТТР 302 браузеры должны использовать тот же самый метод НТТР. Поэтому если 
сауевесога выполнял запрос РОЗТ, браузер должен также применять РОЗТ для запроса 
тидех. Предусмотрен специальный код состояния (303), который означает перенаправление 
с использованием СЕТ. Однако во всех современных браузерах зтим положением специфи- 
кации пренебрегают, используя СЕТ после любого перенаправления 302. Это делается ради 
удобства, поскольку издать НТТР 303 не так-то просто. 
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В двух первых случаях пользовательский браузер рассматривает весь процесс как 
единый запрос НТТР, и в его строке адреса остается /ИмяКонтроллера/зауеВесокга. 
Пользователь может попробовать разместить закладку на этой странице, но это вызовет 
оптибку при последующем обращении к ней (этот ОРГ действителен только при отправ- 
ке формы). Вдобавок пользователь может нажать <ЕБ> для обновления страницы, что 
приведет к повторной отправке запроса РОЗТ и дублированию предыдущего действия. 
Вряд ли такое поведение можно считать приемлемым. 

Именно поэтому третий вариант является наиболее предпочтительным. Вновь за- 
прошенная страница (на /Сопего11егМаме/Тоаех) будет вести себя нормально при 
размещении закладок и обновлении, и обновленное значение в строке адреса имеет го- 
раздо болыне смысла. 


На заметку! Некоторые разработчики относят такой подход к перенаправлению после обработки 
запроса РОЗТ к шаблону проектирования РозУВедйесУ Се! (запрос РОЗТ/перенаправление/ 
запрос СЕТ). 


Перенаправление к другому методу действия 


Как было только что показано, перенаправление к другому методу действия выпол- 
няется просто: 


тебиго Кед1гесЕТоАсЕ1оп ("бопеАсЕ+З оп" 5; 


При этом возвращается объект Веа1кесеТовонеевезио1+, который внутри использу- 
ст средства генерации исходящих ОВ. системы маршрутизации для определения целе- 
вого ОНТ, согласно активной конфигурации маршрутизации. 

Если контроллер не указан (как в последнем случае), это понимается как “на том же 
контроллере”. Имя контроллера можно специфицировать явно, а при желании допус- 
кается также указать другие параметры маршрутизации. которые повлияют на гене- 
рацию ОВ: 


тебагиа Веа1гесеТоАсЕ1оп ("Траех", "Ргоансе$", пем { со1ог = "Вей", раде =2 })}; 


Как всегда, согласно соглашений об именовании МУС Егате\умогк, необходимо просто 
использовать маршрутное имя контроллера (например, Ргодисез}, а не имя класса (те. 
РЕоансЕзСопего1Тет). 

И, наконец, к именованным элементам ВоифеТаЬ1е .Коисе необходимо обращаться 
по имени: 


тегаги ВеЯ1гесеТоКонцте ("Мумамеавонее", пем { сизбопРагам = "ЗотеУа1ае" У 


Генерирующие ОВ!. методы перенаправления, их многочисленные перегрузки, и то, 
как они в действительности генерируют ОКЕ, согласно активной конфигурации маршру- 
тизации, детально рассматривались в главе 8. 


Перенаправление к другому ИРЕ 


Для перенаправления посетителя к ОБ!, выраженному литералом (не используя 
генерацию исходящих ОК!) верните объект Вед1гесевезо1+ следующим вызовом 
Кеа1гесь (): 


тебигп Кеа1тгесе ("ВЕЕр://ими.ехатр1е. сов"); 
Можно также указывать виртуальные пути относительно приложения: 


тебиги Ке@1гесь ("-/боте/Ог1/ти/Му/Арр11саезоп"); 
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На заметку! Как Вед1 гесеТовочеевез11*, так и Вед1хесеВез1 Е издают перенаправление 
НТТР 302, означающее временное перемещение. подобно методу Везропзе .Ве1геске () из 
АЗРМЕТ МеЕопт$. Отличие между ним и НТТР 301 (перемещено постоянно) обсуждалось в 
предыдущей главе. Если вы озабочены поисковой оптимизацией (ЗЕО), удостоверьтесь, что 
используется корректный тип перенаправления. 


Использование коллекции Тетррафа для сохранения 
данных между перенаправлениями 


Перенаправление заставляет браузер отправлять совершенно новый запрос НТТЕ. 
Позтому в новом запросе уже нет того же набора значений контекста запроса, как и 
доступа к любым временным объектам, которые были созданы перед перенаправле- 
нием. Что если понадобится сохранить какие-то данные между перенаправлениями? 
В зтом случае следует обратиться к коллекции Терраса. 

ТепррРаха — это новая концепция, представленная в АЗРМЕТ МУС$. Чего-либо подоб- 
ного в АЗРМЕТ \ебЕЮопиз нет. Она хранит произвольные объекты „МЕТ для текущего и 
следующего запросов НТТР, выполняемых данным посетителем. Это решение идеально 
для кратковременного хранения данных во время перенаправления. 

Давайте вернемся к предыдущему примеру с ЗауевВесога и траех. После сохранения 
записи пользователь должен быть уведомлен о том, что его изменения были приняты и 
сохранены. Но как метод Тпаех () узнает о том, что произотло в предыдущем запросе? 
Для этого необходимо воспользоваться Тепррафа: 


руБ11с Вед1хесеТовосеевезо1е ЗауеВесогка (110% 19, 5Ег1па пемМаще) 

{ 
// Сохранить данные в модели предметной области 
Роша1пМоде1 .Зауе0рдафедВесога (14, пемМапе); 
// Перейти к сетке всех элементов, поместив сообщение о состоянии в ТешрПафа 
Тепррафа ["пеззаде"] = "Уойцк сБапдез +0 " + пемМаме + " Бауе Бееп зауеа"; 
гесагп Вед 1гесЕТоАсЕ1оп ("Тпаех"); 


} 


Во время следующего запроса сохраненное в Тепррата значение можно визуализи- 
ровать в представлении действия Тпдех: 


<5 1Е(ТепрБафа["пеззаае"] != 0011) { $> 
<д1у с1азз="5З6афазМеззаде"><%= НЕ] .Епсоде (ТепрВафка ["пез5аде"]) $></91у> 
<$ } %> 


До появления Тепррафа традиционным способом добиться того же результата была 
передача сообщения о состоянии как значения строки запроса при выполнении пере- 
направления. Однако Тепррафа намного луче: она не порождает длинный неуклюжий 
ОВЬ и позволяет хранить произвольные объекты „МЕТ (а не только строки), поскольку 
всегда остается в памяти сервера. 


—_йЙе.........е.е.:.:.:....еееее"|[||"1п1ПДЗД 


Сравнение хранилищ Тетррафа И Зезз1оп 


На самом деле по умолчанию в основе хранилища Тетррафа лежит хранилище Зеззтоп (по- 
этому, если планируется использовать Тетррафа, не следует отключать хранилище Зезз1оп), 
но Тепрража обладает другими характеристиками. Его уникальная особенность состоит в том, 
что оно является очень кратковременной памятью. Каждый элемент хранится только для одного 
будущего запроса, после чего отбрасывается. Это отлично подходит для хранения объектов при 
вызове Ве 1гесеТоАсЕ1ол ()} , так как потом производится автоматическая очистка. 


С Тетррафа является логическим эквивалентом :#1аз1 в ВиБу оп Райз и коллекции Е1а51[] в 
МороКай. 
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Если вы попытаетесь добиться того же поведения, сохраняя сообщения о состоянии в хранилище 
зезз1оп, вам придется очищать их вручную. В противном случае, когда пользователь вернется к 
действию Тпаех позднее, весьма некстати появится старое сообщение о состоянии. 

При необходимости хранить содержимое Тепрраха где-то вне Зезз1оп, создайте класс по- 
ставщика, который реализует интерфейс ТТепрракаргохтаек, и затем в конструкторе кон- 
троллера присвойте экземпляр поставщика свойству ТетррасаРкоу1аег контроллера. Сборка 
М\УС Геашге$ содержит готовый альтернативный поставщик Соок1еТепррафаРго\1 Чек, кото- 
рый сериализует содержимое Тетррага в сооке-набор браузера. 


Ве Е КР. И + А 
Возврат текстовых данных 


Помимо НТМЕ, существует множество других основанных на тексте форматов дан- 
ных, которые может понадобиться генерировать приложению. К распространенным 
примерам относятся: 


« ХМГ, 

° В55 и АТОМ (подмножества ХМГ) 

® ЗЭОМ (предназначен обычно для приложений Адах) 

® СЗУ (предназначен обычно для экспорта табличных данных в Ехсе]) 
® Простой текст 


В АЗР.МЕТ МУС имеется специальная встроенная поддержка генерации данных 
ЗЗОМ (которая будет описана ниже), а для всех прочих можно использовать тип возвра- 
та действия СопеепеВез111 +. Чтобы успешно вернуть любой формат данных на основе 
текста, потребуется указать три вещи. 


® Сами данные в виде зе г1поа. 


® Заголовок сопеепе-куре для отправки, например, сехе/хи1 для ХМГ, Еехе/сзу 
для СЗУ и арр11са 1оп/гзз+хи] для В3$. Их можно получить из значений клас- 
са Зузфет.Меф.М1те .МеЯ1аТурематез. С помощью такого заголовка браузер ре- 
тает, что делать с ответом. 


° Используемая кодировка текста (необязательно). Она описывает. как преобразо- 
вать экземпляр .МЕТ зе г1п9 в последовательность байтов, которые могут быть пе- 
реданы по сети. К. примерам кодировок относятся ОТЕ-8 (весьма распространена 
в Интернете), АЗСП и 130-8869-1. Если значение не указано, будет предпринята 
попытка выбрать кодировку, поддержку которой требует браузер. 


Все это можно специфицировать с помощью объекта Сопкеп+везла1 +. Чтобы создать 
его, просто вызовите метод Соптеп+ (), например: 


риБ11с Асе1опВезо1е б1уеМер1а1пТех+ () 
{ 

гебики Сопфеп® ("ТЬ15 1$ р1а1п фехЕ", "кехё/р1алт"); 

// Или замените "фехе/р1а1п" на Мед1аТуреМапез .Техе.Р1а1п 
} 


Если вы возвращаете текст и не заботитесь о заголовке сопеере-+ уре, можете ис- 
пользовать сокращенный вариант, возвращая зЕг1пд непосредственно из метода дей- 
ствия. Каркас преобразует строку в Сопеепевези1 +: 


рую11с зЕх1па С1уеМер1алиТехе () 
{ 


тероги "Простой текст"; 
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Фактически, если метод действия возвращает объект любого типа, не унаследованно- 
го от АСЕ1опВези1*, то МУС Егате\уюогК преобразует возвращаемое значение метода дей- 
ствия в строку (используя Сопуеге.То5ег1па (возвращаемое3начение, Со1охгеТиго. 
Тпуаг1апеСо1ел ге) ) и сконструирует СопеептВези1*, используя это значение. Это мо- 
жет пригодиться, например, в некоторых сценариях Адах, если просто нужно вернуть 
сита или другой маркер браузеру. Обратите внимание, что параметр сопеепеТуре не 
указан, поэтому используется его значение по умолчанию (6ехе/ВЕт1). 


Совет. Это поведение преобразования результирующих объектов в строки можно изменить. Пусть, 
например, необходимо, чтобы методы действий имели возможность возвращать произвольные 
сущности предметной области, упакованные и доставляемые браузеру в определенном виде 
(возможно, в зависимости от входящего НТТР-заголовка Ассерт). Это может стать базой для 
каркаса приложений ВЕ$Т. Создайте специальный класс инициатора действия, унаследовав его от 
СопЕко11етАсЕ1опТпуокег и переопределив его метод СтеатеАст1опВези1* (). Затем присвой- 
те свойству АсЕ1оптпуокег контроллера экземпляр этого специального инициатора действия. 


Построение А$$-канала 


В качестве примера использования СопёепЕВези1е посмотрите, насколько легко 
можно создать канал В$5 2.0. Для начала сформируем документ ХМТ, используя для 
этого элегантный АР!-интерфейс .МЕТ 3.5 Хросишеп*, и отправим резульгирующий до- 
кумент браузеру с помощью метода Сопеепе (). как показано ниже: 


риБ11с СопеепЕВезо1е В$5Ееечд () 
{ 
Зеогу[] эЕок1ез = бееА115от1ез(); // Получить из базы данных или откуда-то еще 
// Построение документа ВК5$5-канала 
ЗЕг1па епсо@а1па = Везропзе .Сопфеп Ептсоа1та .ИеБМапе; 
ХРосимейЕ гз$ = пеи ХРоситеп® (пем ХРес1агае1оп ("1.0", епсо@1та, "уез"), 
пеи ХЕ1ещепе ("гзз", пем ХАЕЕг1росе ("уегзлоп", "2.0"), 
пем ХЕ1епепе ("сваппе1", пеи ХЕ1емепе ("©11е", "Ехапр1е 85$ 2.0 Еее"), 
Егош збогу 10 због1ез 
зе1есЕе пем ХЕ1епепф ("1еем", 
пеи ХЕ1ещепф ("{141е", збогу.Т1Е1е), 
пем ХЕ1ещеп ("дезсе1ре1оп", эвогу.РезскарЕ1оп), 
пеи ХЕ1етепф ("11пК", эеогу.0т1) 


); 
гебоаги Сопеепе (тз5.Тобек1па (), “арр11са®1оп/гзз+хи1"); 
} 


Болыпинство современных веб-браузеров распознают тип содержимого арр11са&1оп/ 
Е55+х11 и отображают подписку в хорошо оформленном читабельном для челове- 
ка формате либо предлагают добавить ее в средство чтения В55-каналов как новую 
подписку. 


Возврат данных У$ОМ 


УЗОМ (ФахуаЗсеирё ОЦесЕ Моайоп — объектная нотация Зауа5 ср) — зто текстовый 
форматданных общего назначения, описывающий произвольные иерархические структу- 
ры. Если выражаться точнее, то зто практически код Зауабсйрь, потому он естественным 
образом поддерживается гючти любым веб-браузером (причем намного легче, чем ХМП). 
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За дополнительными подробностями обращайтесь по адресу Вер: //иии.] зоп.ога/ 
Эзоп-ки. Вет. 

Чаще всего формат У5ЭОМ используется в приложениях Адах для отправки объек- 
тов (включая коллекции и полные графы объектов) из сервера в браузер. В АЗРМЕТ 
МУС имеется встроенный класс 9зопВези1%&, который заботится о сериализации объ- 
ектов .МЕТ в виде УЗОМ. Сгенерировать ЗзопВезо1е можно с помощью вызова метода 
9зоп (): 


с1аз5 С1фурафа { рую11с зек1па с1фу; рую11с 116 сепрега®оге; } 
рур11с АсЕ1опВези1е МеакВеграфжа () 
{ 
уаг с11езАггау = пем[] { 
пем С1фураба { с1Фу = "Гопаоп", сепрегабаге = 68 }, 
пеи С1ЕуБаба { с1Фу = "Норд Копа", Фепрегабоге = 84 } 
}; 
тебаги УЧзоп (с1(1езАгкау); 
} 


Массив с1Е1езАггау передается в формате ЗЗОМ: 
[{"с1Фу" : "Топдоп", "сетрегабаге" :68}, {"с1фу":"Нопа Копа", "Еетрегакаге" :84}] 


Кроме того, заголовок ответа сопеепе-суре будет установлен в арр11саЕ1оп/) оп. 

Не беспокойтесь, если пока не понимаете, как используется 4ЗОМ. Исчерпывающие 
объяснения будут представлены в главе 12 вместе с демонстрацией его использования 
с Адах. 


Возврат команд Чама$ сир: 


С помощью методов действий запросы ах могут обрабатываться так же легко, как 
и обычные запросы. Как было показано ранее, с использованием УзопВези1% метод 
действия может возвращать произвольную структуру данных 3ЗОМ, с которой код кли- 
ентской стороны может проводить какие угодно манипуляции. 

Однако иногда требуется ответить на вызов Адах непосредственно, поручив браузе- 
ру выполнение определенного оператора ЗахаЗс"рё. Это делается с помощью метода 
ЗауаЗск1р+ (), который возвращает результат типа дауа$сг1реВези1, например: 


ру611с Фауабст1рЕКез1е ЗауНе]11о() 
{ 

тебагп Зауа$стг1р® ("а1егь ('Не11о0, иог1а!');"); 
} 


Для того чтобы мегод бауНе11о () заработал, необходимо сослаться на него с исполь- 
зованием вспомогательного метода А] ах.АсЕтопрГ1юКк() вместо НЕш1 .АсеторЬтиК (). 
Например, добавьте в представление следующий код: 


<%= А]лах.Асе1опЬ1ик ("С11сК пе", "бауНе11о", по11) $%> 


А]ах.Асе1опЬ1оКк() похож на НЕп1.АсетопГлик() тем, что визуализирует ссылку 
на действие бауНе11о. Отличие А} ах.Асе1орт1иок() состоит в том, что вместо запуска 
обновления всей страницы осуществляется асинхронный запрос (также называемый 
Аах-запросом). После щелчка пользователем на конкретной ссылке Адах соответствую- 
щий оператор ЗахаЗсйрЕё извлекается из сервера и немедленно выполняется, как пока- 
зано на рис. 9.3. 

Скорее всего, вы будете использовать объект Зауа$сг1рЕВези1& не для отображе- 
ния дружественных сообщений, а для обновления ООМ-модели отображаемой НТМ1.-- 
страницы. 
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[ 38 Ных/лосаозЕБ262А Екатре - ВНеглей Ехрогег 


Рис. 9.3. Отправка команды амаЗ сир! из сервера в браузер 


Например, после вызова метода действия, удаляющего запись из базы данных, возни- 
кает необходимость удалить соответствующий элемент РОМ из списка в браузере. Более 
полное описание вспомогательных методов Азах.* будет дано в главе 12. 


На заметку! Формально объект ?ауа$ск1рЕВези1+ — это тот же самый объект СопеепеВези1 к, 
за исключением того, что Зауа$ сх1рЕВези1& жестко закодирован для установки заголовка 
сопрепе-буре в арр11саЕ1оп/х-]ахазск1ре. Встроенный в АЗРМЕТ МУС вспомогатель- 
ный сценарий Адах под названием М1 скозоЕЕМусАзах .  з специально проверяет значение 
заголовка сопеепе-Фуре, и когда находит его, то знает, что ответ нужно трактовать как ис- 
полняемый код уамаЗсирь, а не текст. 


Возврат файлов и двоичных данных 


Как быть, если необходимо отправить файл в браузер? При этом может потребовать- 
ся, чтобы для, скажем, ЛР-файла браузер открыл диалоговое окно загрузки с возможно- 
стями сохранения и открытия файла, а для файла с графическим изображением пока- 
зал его содержимое непосредственно в своем окне (как это делалось в конце главы 6). 

Е11сегВези1+ — это абстрактный базовый класс для всех резульгатов действий, 
связанных с отправкой двоичных данных в браузер. АЗРМЕТ МУС поставляется с тремя 
конкретными подклассами, готовыми к использованию: 


® Е11ерРаВВези1Е — отправляет файл непосредственно из файловой системы 
сервера; 

® Е11еСопеепеВези1Е — отправляет содержимое байтового массива (руке []) из 
памяти; 


® Е11е5хгеамВез1е — отправляет содержимое объекта Зузсет.тТО.5егеамт, кото- 
рый должен быть уже открыт. 


Как правило. заботиться о том. каким подклассом Е11еВеза1* воспользоваться, не 
нужно, поскольку экземпляры всех трех можно создать вызовом различных перегрузок 
метода Е11е (}. Ниже приведены примеры применения каждой из них. 


Отправка файлов непосредственно с диска 


С помощью одной из перегрузок метода Е11е () можно отправить файл непосредст- 
венно с диска: 


роБ11с Е11еРаЕ№Вези1е Роип1оа@Верокге () 
{ 
зЕг1па Е11епаще = @"с:\Е11ез\зоцшеЕ11е.ра#"; 
гееагп Е11е (Е11епаме, "арр11са®1оп/раЕ", "Аппиа1Верог*.раЕ"); 
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Приведенный вызов Е11е () заставляет браузер открыть диалоговое окно загрузки с 
возможностями сохранения и открытия файла, показанное на рис. 9.4. 
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Рис. 9.4. Диалоговое окно загрузки с возможностями 
сохранения и открытия файла 


Эта перегрузка Е11е () принимает параметры, перечисленные в табл. 9.3. 


Таблица 9.3. Параметры, передаваемые =31е (} для отправки файла непосредственно с диска 


Параметр Тип Назначение 

{1 1епаме (обязательный) зЕк1п9 Путь кпередаваемому файлу (в файловой системе сервера). 
сопЕепЕТуре 3Ег1п9 Тип МИМЕ для использования в заголовке соптепт-туре 
(обязательный) ответа. На основе этой информации о типе ММЕ браузер при- 


нимает решение об обработке файла. Например, если указан 
Тип арр11саЕ1оп/упа.мз-ехсет1, то браузер должен будет 
открыть файл в Мисгозой Ехсе|. Аналогичным образом ответы 
арр11сат1оп/раЕ должны открываться в выбранном пользо- 
вателем средстве просмотра РОЕ-документов *. 


Е1}ероип1оаЯ Мате зее1па Значение заголовка сопеепЕ-&1эроз1Е1оп для отправки с 

(необязательный) ответом. Когда этот параметр указан, браузер должен всегда 
открывать диалоговое окно загрузки с возможностями сохране- 
ния и открытия для загружаемого файла. Браузер должен трак- 
товать это значение как имя загружаемого файла, независимо 
от УВЕ, с которого этот файл был загружен. 


* Расширенный список стандартных типов МИМЕ доступен по адресу ит. запа.отд/аззЯоппепез/пед1а-Курез/. 


Если параметр Е11ероип1оаЯМаме опущен, и браузеру известно, как отображать оп- 
ределенный тип МИМЕ (например, все браузеры умеют отображать файлы 1таде/ч1)}, 
то браузер просто отобразит этот файл самостоятельно. 

Если параметр Е11еронп1оаЯМате опущен, но браузер не знает, как отображать 
указанный тип ММЕ (например, когда задано арр11сак1о0п/ура.тз-ехсе1)}, то брау- 
зер должен вывести диалоговое окно загрузки с возможностями сохранения и открытия 
файла, определив имя файла на основе текущего ОВ (в пуегпеё Ехрогег — на основе 
указанного типа ММЕ). Однако предложенное имя файла почти наверняка не будет 
осмысленным для пользователя, поскольку оно может иметь расптирение, не соответ- 
ствующее его типу, такое как .шус, или вообще не иметь расптирения. Поэтому не за- 
бывайте о параметре Е11ероип1оаЯ Маме, когда ожидаете появления в браузере диало- 
гового окна загрузки с возможностями сохранения и открытия файла. 
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Внимание! В случае указания Е11еПоип1оа@Мапе, не согласующегося с соптепеТуре (например, 
в качестве имени файла задано Аппиа1Вероге „рае, а в качестве типа МММЕ — арр11саЕ1оп/ 
УПа.пз-ехсе1), результат будет непредсказуемым. Браузер Еиеюх 3 попытается открыть 
файл в Ехсе!, в то время как !егпе! Ехрюгег 7 — в средстве просмотра РОЕ-документов. Если 
вы не знаете, какой тип М!МЕ соответствует отправляемому файлу, можете указать для типа 
арр11са 10 /оскек-зегеан. Это означает “двоичный файл неопределенного типа”. В этом 
случае браузеру будет принимать собственное решение о том, как обрабатывать этот файл, 
обычно на основе его расширения. 


Отправка содержимого байтового массива 


Если двоичные данные располагаются в памяти, их можно передать с использова- 
нием другой перегрузки Е11е (): 


риуЮ11с Е11еСопфепеВезо1е Поип1оааВерокге () 
{ 
Бусе[] дафа = ... // Сгенерировать или каким-то образом 
// получить содержимое файла 
гекигп Е11е (Чафа, "арр11са1оп/раЕ", "Аппаа1Верокг®.раЕ"); 
} 


Такой подход применялся в конце главы 6 при отправке графического изображения, 
извлеченного из базы данных. 

В этой перегрузке Е11е () параметр сопрепеТуре также является обязательными, а 
Е11еРоип1оа@Я Мате — необязательным. Оба параметра трактуются в точности так, как 
было описано выше. 


Отправка содержимого потока 


И, наконец, если данные, которые необходимо отправить, поступают из открытого 
потока Зузсеш.ТО.5Егеам, читать его целиком в память перед отправкой клиенту в 
виде байтового массива не понадобится. Вместо зтого можно указать Е11е () переда- 
вать данные потока по мере доступности каждого фрагмента данных: 


рир11с Е11е5хеамКези1е РгохуЕхапр1еро*Сом () 

1 
мерс11ерЕ мс = пем ИебСс11епе(); 
ЗЕгеат зЕгеам = мс .ОрепВеа4 ("ВЕЕр://иии.ехатр1е.сош/"); 
гееаги Е11е(з&геаш, "фехе/веи1"); 

} 


И в зтой перегрузке Е11е () параметр сопеепеТуре является обязательными, а 
Е11ероип1оабМате — необязательным. Оба параметра трактуются в точности так. как 
было описано выше. 


Создание специального типа результата действия 


Встроенных типов результатов действий достаточно для болынинства случаев, с ко- 
торыми вы столкнетесь. Тем не менее, очень легко создать собственный тип результата, 
наследуя его от одного из встроенных типов или даже непосредственно от АсЕ1опвези1+. 
Единственный метод, который потребуется переопределить — это Ехесокевези1* (). 
Не забудьге предоставить достаточное количество общедоступных свойств для модуль- 
ных тестов, чтобы можно было проверить объект резульгата действия и понять, что в 
нем происходит. Далее будет представлен соответствующий пример. 
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Пример: изображение с водяными знаками 
(и концепция швов тестируемости) 


Предположим, что создается веб-сайт для хранения фотографий. Его функциональ- 
ность предусматривает обработку файлов изображений. в частности, наложение текста 
на изображения. Такой текст, имеющий вид водяных знаков, может генерироваться ди- 
намически, иногда указывая имя фотографа, а иногда — цену изображения либо инфор- 
мацию, касающуюся лицензирования. 

Каким образом проверить, что каждый такой метод действия накладывает на изо- 
бражение корректный текст? Должны ли быть построены модульные тесты, которые 
вызывают метод действия, получают данные изображения и затем с помощью какой- 
нибудь библиотеки оптического распознавания символов определяют, какой текст был 
наложен на изображение? Возможно, процесс реализации и будет интересным, но, от- 
кровенно говоря, заниматься этим не стоит 

Способ решения данной задачи заключается во введении шва тестируемости 
(Еезаы Шу зеап): промежутка между прикладным кодом, который решает, какой текст 
накладывать, и остальной частью кода, которая действительно визуализирует выбран- 
ный текст на изображении. В этот промежуток могут быть помещены модульные тесты, 
которые будут проверять только ту часть кода. в которой принимается решение относи- 
тельно накладываемого текста, и игнорировать нетестируемую часть кода, визуализи- 
рующую этот текст на изображении. 

Замечательным способом реализации такого шва тестируемости является специ- 
альный результат действия, который позволяет методу действия указать, что нужно 
делать, не выполняя это фактически. Специальный результат действия также облегча- 
ет повторное истользование функциональности водяных знаков во множестве методов 
действий. 

Давайте теперь рассмотрим собственно код. Приведенный ниже специальный ре- 
эультат действия накладывает текст водяных знаков на изображение, после чего пере- 
дает изображение в формате РМС (независимо от исходного формата): 


ру611с сЛаз5 Иабегтагке Тнадекези1е : АсЕ1опВези1Е 
{ 
ру611с зЕг1ра ТиадеЕ11еМаще { де; рглуафе зе; } 
ро611с зеклиа МасегщахкТехе { деф; рг1уафе зе{; } 
рую11с ИасегтаткедТтадевеза1 + (5&г1п4д 1тадеЕ11еМаме, з&х1пд иабегтагКТехе) 
{ 
ТпадеЕ11еМаще = 11адеЕ11еМапе; 
МафегиатКТехе = иакегиакКТехс; 


} 


ру611с оуегг14е уо19 ЕхесаеВезо14 (Сопего11ехСопфехе сопеехе) 
{ 
и51п9 (уаг 1щаде = Тваде.ЕгоцЕ11е (ТтадеЕ11еМапе) } 
15109 (уаг дхарЬ1сз = СгарЬ1с$ .ЕгошТщаде (1таде) ) 
115119 (уаг Еопе = рем Еопе("Аг1а1", 10)) 
115119 (Уаг мепогу5©геам = пем Метогу5®геам ()) 
{ 
// Визуализировать текст водяного знака в нижнем левом углу 
Уаг +ехЕ51те = дгарь1с$ .Меазиге5т1па (МабегтакКТехе, Еоп®); 
дхарь1с$ .Ргам5г1па (ПабегиатКТехе, Еопе, ВхозВез.МИ1Фе, 10, 
1паде.НелавЕ - $ехЕ51хе.Нелане - 10); 


// Передать изображение в формате РМС (примечание: сначала 
// буферизировать в памяти из-за ограничений СОТ+) 
1паде .Зауе (пепогу5геаш, Тпадегохтат .Рпа); 
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уаг гезропзе = сопеехЕ .Ведиез Сопеехе .НЕЕрСопеехь .Везропзе; 
тезропзе.СопсептТуре = "1таде/рпа"; 
тезроп5е .В1пахуйх1е (шетогу5 геам. сееВаЕЕег (а 


} 


Имея такой код, на изображение можно наложить метку с текущим временем, ис- 
пользуя метод действий, как показано ниже: 


ру611с с1аз5 ИатегтаккКСопеко11ег : СопЕго11ег 
{ 
ре1уабе зба®1с 5611049 Ттадезр1хескогу = @"с: \1тадез\"; 
р9Ю11с Мабегтатке@Ттадекези1% СефТтаде (5%+х1пд Е11еМапе) 
{ 
// Для безопасности принимать файлы изображений из определенного каталога 
уаг Е011РаЕв = Ра®в .Соп1пе (ТмадезГ1гессоку, Рабр .сбефЕ11еМапе (Е11еМапе)); 
56к1па мафегиагКТехе = "Тре +1ще 15" + РасеТ1те .Мом.ТобвохеТ1ие$к1поа (); 
тебагп пем МасегиагкедТиадевез 1% (Еи11Рафв, масегиагкТех®) ; 


} 


Теперь изображение с водяными знаками можно отобразить, добавив в шаблон 
представления соответствующий дескриптор <1п9>: 


<19 зтс="<%= 0т1.АсЕ1оп ("Се Ттаде", "Иафегтатк", пем {Е11еМаше="1етиг.)ред"}) $>" /> 


Результирующее изображение показано на рис. 9.5. 


2 Бру Асс но3с 62424. 


прееныт Па ео ке 


НЕ о Нам я жа те 


Тв зовае ноге Тех бон Фе ету Фета. 


итеиываант ал 


Рис. 9.5. Вывод изображения с наложенной 
меткой с текущим временем 


Для проверки метода сееТпасде() класса ИакегиагкСоп+го11ег можно напи- 
сать модульный тест, который вызовет зтот метод, получит результирующий объект 
Масегиагке Тиадевези1+ и с помощью его свойств ТтадеЕ11еМаме и МатегпагКТехе 
определит, какой текст будет накладываться на каждое графическое изображение. 

Разумеется, в реальном проекте код следовало бы сделать более универсальным, из- 
бавившись от жесткого кодирования имени шрифта, размера, цвета и каталога. 
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Использование фильтров для подключения 
повторно используемого поведения 


Добавить дополнительную функциональность в контроллеры и методы действий 
можно, декорируя их фильтрами. Фильгры — зто атрибуты „МЕТ, которые добавляют 
дополнительные птаги в конвейер обработки запросов, позволяя встраивать дополни- 
тельную логику перед и после запуска методов, перед и после выполнения результатов 
действий, и даже предусматривать определенные действия в случае возникновения не- 
обработанного исключения. 


Совет. Если вы не знакомы с концепцией атрибутов .МЕТ, почийте о них сейчас. Атрибуты — это спе- 
циальные классы .МЕТ, унаследованные от Зузе еп .АеЕг1Бофе, которые можно присоединять 
к другим классам, методам, свойствам и полям. В С# зто делается с помощью синтаксиса квад- 
ратных скобок. При этом можно также заполнять общедоступные свойства атрибутов согласно 
синтаксису именованных параметров (например, [МуАЕЕк1Ьее (Зошергорегку=уа1е) ]). 
В соответствии с соглашением об именовании, принятым в компиляторе С#, если имя класса 
атрибута завершается словом АЕЕг1рихе, зту часть имени можно опускать (например, вместо 
АЛЕВох12еАЕЕЕк1раке указывается просто [АцЕВог1=е]). 


Фильгры — ясный и мощный способ реализации перекрестных видов ответст- 
венности. Это означает поведение, которое используется повсеместно, но не разме- 
щается в каком-то одном месте традиционной объектно-ориентированной иерархии. 
Классическими примерами могут служить протоколирование, авторизация и кэширо- 
вание. Примеры фильгров уже были представлены ранее (например. в главе 6 фильтр 
[АзеВог1;е] применялся для обеспечения безопасности Ади1пСопего11етх в приложе- 
нии рой фюоге). 


На заметку! Эти атрибуты называются фильтрами потому, что аналогичный термин используется для 
эквивалентного понятия на других платформах веб-программирования, включая Вибу оп Вай$. 
Однако они не имеют никакого отношения к объектам Веслезе .Е11+ех и Везропзе .Е11{ег 
ядра АЗР МЕТ, так что не путайте их! Объекты Вечиезе.Е11%ег и Везропзе .Е11%ек при- 
меняются и в АЗРМЕТ М\УС (например, для трансформирования выходного потока — сложная 
и необычная операция), но когда программисты АЗРМЕТ МУС говорят о фильтрах, обычно они 
имеют в виду нечто совершенно иное. 


Четыре базовых типа фильтров 


В МУС ЕгатемогК определены четыре базовых типа фильтров, которые перечислены 
в табл. 9.4. Эти типы позволяют встраивать логику в разные точки конвейера обработ- 
ки запросов. Обратите внимание, что АсЕ1опЕ1 1 вехАЕЕг1рике является реализаци- 
ей по умолчанию для обоих интерфейсов ТАСЕ1опЕ11%ех и ТКезо1Е11 ет. Это наибо- 
лее универсальный фильтр, фактически помеченный как абз®гас®, поэтому он служит 
только для наследования от него конкретных подклассов. Тем не менее, другие реализа- 
ции по умолчанию (Ацепог12еАеег1рисе и Нап91еЕгкогАЕЕк1Ьиее) являются конкрет- 
ными, содержат полезную логику и могут использоваться без создания подклассов. 

Чтобы лучше понять эти типы и отношения между ними, взгляните на рис. 9.6. На 
нем видно, что все атрибуты фильгра унаследованы от Е11ЕекАбег1риасе и реализуют 
один или более интерфейсов фильгров. С помощью темных прямоугольников обозначе- 
ны готовые к применению конкретные фильтры, а остальные соответствуют интерфей- 
сам и абстрактным базовым классам. Дополнительные сведения о каждом встроенном 
типе фильтра будут даны далее в этой главе. 
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Таблица 9.4. Четыре базовых типа фильтров 
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Тил фильтра 


Интерфейс 


Когда запускается 


Реализация по умолчанию 


Фильтр авторизации 


Фильтр действия 


Фильтр результата 


Фильтр исключения 


ТАОбВог1 27а 1опЕ11 еек 


ТАСЕТопЕ11ек 


ТВезо16Е11{ег 


ТЕхсере1опЕ11 еек 


Первым, перед запуском 
любого другого фильтра 
или метода действия. 


Перед или после запуска 
метода действия. 


Перед или после запуска 
результата действия. 


Только в случае, если 
другой фильтр, метод 
действия или результат 
действия генерирует не- 
обработанное исключение. 


АцЕНох17еАсст1роте 


АСЕТорЕ1 1 етАЕЕтарофе 


АсстопЕ11СехАЕЕтаросе 


НапО1еЕхгогА © х1рабе 


ит 


Абстрактный 
базовый класс 
для всех 
атрибутов .МЕТ 


+ {АНегАНИЬЫе }, < 


Абстрактный 
базовый класс 
для фильтров 


МайдаеАпРогдегутоКепАНище 


ОшриСаспеАНньше 


АшпогиеАНИоие 


\УайчаеприАНиьше 


НапфеЕггогАННБше 


Рис. 9.6. Иерархия классов фильтров, встроенных в АЗРМЕТ М\УС 


Для реализации специального фильгра необходимо создать класс, унаследованный 
от Е11секАсске1расе (базового класса всех атрибутов фильтров}, и затем реализовать 
один или более из четырех интерфейсов фильтров. Например, Аа Бог хедАЕк1Ьике 
наследуется от Е11<ехАсск1рифе и также реализует ТАЗЕВог1хае1отР1 ег. Однако 
обычно беспокоиться об этом не нужно, поскольку в большинстве случаев можно на- 
прямую использовать конкретные реализации по умолчанию или наследовать от них 


подклассы. 


Применение фильтров к контроллерам 
и методам действий 


Фильгры можно применять либо к индивидуальным методам действий, либо ко всем 
методам действий заданного контроллера, например: 
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[Амфрогахе (Ко1ез="Етхадех") ] // Применяется ко всем действиям контроллера 
раб11с с1азз 5ЕоскКТкаЯ91паСопекоТек : Сопеко11ек 
{ 


[ОцпериЕСасве (Рига&1оп-=60)] // Применяется только к этому методу действия 
рию11с \У1емВези1е СигкепЕВ1зкботпаку () 


{ 
//... ит.д. 
} 
} 


На любом уровне можно применять сразу несколько фильгров, управляя порядком 
их выполнения с помощью свойства Огаег базового класса Е11кекАкег1рисе. Вопросы 
управления порядком выполнения фильтров и распространения исключений рассмат- 
риваются далее в этом разделе. Теоретически это может оказаться довольно сложным, 
но на практике нужное поведение фильтров реализуется относительно просто. 


На заметку! Если классы контроллеров унаследованы от специального базового класса, то атри- 
буты фильтров, примененные к базовому классу (или его методам), будут также применены к 
классам-наследникам контроллеров (или к переопределенным в них методам). Причина в том, 
что класс Е11секАЕсг1Бифе помечен как Тпвег1теа = $ кие, а данный механизм относит- 
ся к самой платформе .МЕТ, а не к АЗРМЕТ М\С. 


Чтобы прояснить, как упомянутые выше четыре типа фильтров сочетаются с вы- 
полнением метода действия, взгляните на показанный ниже псевдокод. Он прибли- 
зительно представляет то, что делает СопЕхо11екАс&1опТпуоКекгк в своем методе 
ТихокеАсЕтол (). 


фку 
{ 
Запустить каждый метод ОпАирог1хаелоп() на ТАДЕВоОг12а&1опЕ11фек 
1: (ни один из ТАСЯЕВОг17ае1отЕ11(ехт не прервал выполнение) 
{ 
Запустить каждый метод ОпАск1опЕхеси®1т9 () на ТАС&1опЕ11$ек 
Запустить метод действия 
Запустить каждый метод ОпАс®лопЕхесифей() на ТАС&1опР11 ет (в обратном порядке) 
Запустить каждый метод ОпВези1ЕЕхесиЕ1т9 {() на ТВезо1ТЕЕ11 ет 
Запустить результат действия 
Запустить каждый метод ОпВези1Ехесиеей() на ТВезо1ЕЕ11Еег (в обратном порядке) 
} 
е?тзе 
{ 
Запустить любые наборы результатов, установленные фильтрами авторизации 
} 
} 
саесв (исключение, не обработанное ни одним из действий или фильтров результатов) 
{ 
Запустить каждый метод ТЕхсер®1опР11екг ОпЕхсерЕ1ол () 
Запустить каждый набор результатов, установленный фильтрами исключений 


} 


Этот псевдокод отражает общую картину того, что и когда происходит, но недоста- 
точно точно, чтобы исчерпывающе описать распространение исключений вверх через 
фильтры действий и результатов и то, как их можно обработать перед достижением 
фильтров исключений. Об этом речь пойдет позже. 

Сначала давайте познакомимся поближе с каждым из четырех базовых типов 
фильтров. 
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Создание фильтров действий и фильтров результатов 


Как упоминалось ранее, универсальные фильгры действий и результатов — это ат- 
рибуты МЕТ, унаследованные от Е115ехАеек1рисе, который также реализует интер- 
фейсы ТАСЕ1опЕ11%ег или Тгези1%Е115ег. Однако вместо создания чего-то подобного 
с нуля проще унаследовать подкласс от встроенного Асе1опЕ11ЕегАЕсг1рифе. Это даст 
комбинацию фильгра действия и фильтра результата (он реализует оба интерфейса), и 
тогда останется только переопределить интересующие методы. 

В интерфейсах ТАСЕ1опЕ111 ег и [Вези1%Е11сех есть четыре метода, соответствую- 
щие четырем разным местам в конвейере обработки запросов, куда можно внедрить 
специальную логику. Эти методы описаны в табл. 9.5 и 9.6. 


Таблица 9.5. Методы тасетопЕ11ех 
{их можно также переопределить в АСЕ опЕ11ЕекАЕЕЕЬике) 


Специальные операции, которые 


Метод Когда вызывается 
можно выполнять в методе 
ОПАСЕ1опЕхесиЕ 119 (} Перед запуском Предотвращение выполнения метода действия за 
метода действия счет присваивания свойству {11%$ехСопеехе. 
Вези1 объекта Асе1орВези1+. 
Просмотр и изменение +#11+етСопфехеЕ. 
Асе1опРагатефетз, которые будут использо- 
ваться при вызове метода действия. 
ОпАсЕтопЕхесиесея@ () После запуска Получение деталей любого исключения, 
метода действия сгенерированного методом действий из 


Е11се’Сопфехе.Ехсере1 он, и дополнительная 
пометка его как обработанного” путем установки 
{1ТеегСопбех® _Ехсер®1опнапд1Теа в Е кие. 


Просмотр и изменение АсЕ1опВезит+ через 
{1 1фегСопеехе.Вези1е. 


* Если не установить Е11сегСопеех®.Ехсер&1опНапо1еа в кие, исключение будет распростра- 
няться до следующего фильтра в цепочке. Вскоре вы узнаете больше об этом механизме. 


Таблица 9.6. Методы твези1Е11ех 
(их можно также переопределить в АсЕ1опЕ11ЕехАЕЕЕ1Ьие) 


Специальные операции, которые 


Мет зывается 
А Ко ВызНва можно выполнять в методе 
Опрези1Ехесие1т9 () Перед запуском Просмотр (без возможности изменения) 
АСЕ1ТопВези1% АСсЕ1опВези1& через Е11ЕегСопеехе.Вези1е. 
Предотвращение выполнения Асе1топВези1 пу- 
тем установки Е11тегСопфех® .Сапсе]1 в кие. 
Опвези1ЕЕхесикед () После запуска Получение деталей любого исключения, сгенери- 
АСЕ1опВези1 рованного АсЕ1орВези1 из #11$екСопфех®. 


Ехсере1оп, и дополнительная пометка его как об- 
работанного* путем установки Е11кегСопеехе. 
ЕхсерЕ1опНапа1{еа в фгие. 


Просмотр (без возможности изменения) 
АсетопВези1 Е через Е11ЕетСопеехе .Вези1 Е. 
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Во всех четырех случаях передается параметр контекста Е11сегСопфех\, который 
позволяет считывать и записывать некоторый диапазон объектов контекста. Например, 
он предоставляет доступ к ВедаезЕ и Везропзе. Ниже приведен несколько надуманный 
пример, который демонстрирует все четыре точки внедрения, производя запись непо- 
средственно в Везропзе: 


руБ11с с1азз ЗромМеззадедеек1Бике : АсЕ1опЕ11кекАкскараке 
{ 
раБТ1с з6г1п9 Меззаае { деф; зе®; } 


рую11с оуегг1ае уола ОпАсЛопЕхесие1пт9 (Асс1опЕхеси1п9Сопеехе Е116егСопфех®) 
{ 

11 секСопфсехе. НЕЕрСопсехе .Везропзе.Иг1Те (" [ВеогедАСЕ1оп " + Меззаде + "]"); 
} 


роБ11с отегг14е уо1а ОпАс&1опЕхесиеед (АсстопЕхесиейдСор®ехе #11фехСопеех®) 


{ 


Е11СегСопфех® .НесрСопеехе .Везропзе.Мт1{е (" [АЕсекгАс®1от " + Меззасде + "]"); 
} 


руб с оуекг1ае уо1а ОпВези СЕхеси&1пт9 (везиЕхесислпаСопеехе Е11егСопеех®) 
4 

Е11сегСопеех® .НЕЕрСопфехк .Везропзе.Иг1 се (" [ВеЕогеВези1{ " + Меззаде + "]"); 
} 


руБ11с отегу1ае уо1А ОпВези1ЕЕхесиеед (Везо ЕхесикедСоп®ехе #11+екгСопеех®) 
{ 
#11 сегСопсехе .НЕЕрСопеех®е.Везропзе.Итг1{е (" [АЁсегВези1% " + Меззаде + "]"); 
} 
} 


Если присоединить этот фильтр к методу действия, например, так: 


роБЪас с1азз Е11фегзретоСопЕко11ег : Сопеко11ех 
{ 
[ЗБоиМеззасде (Меззаде = "Нонау") ] 
ри611с АсЕ1опвВези1е ботедсетоп () 
{ 
Вевропзе .Иг1 Ее ("АСЕ1оп 1$ кипп1то"); 
хегагп Сопфеп® ("Везо1е 1$ гирп1ро"); 
} 
} 


будет получен следующий результат (для ясности добавлен разрыв строки): 


[ВебокеАсе1оп Номду]Асе1оп 1$ кипп1па[АЕбекАс®1оп Ноиау] 
[ВебогеВези1® Номау]Вези1 1$ кипп1па [АЕбегВезо1е Номау] 


Управление порядком выполнения фильтров 


С одним методом действия моно связать сразу несколько фильтров: 


[ЗВоиМеззасде (Меззасде = "А") ] 
[ЗВоМеззаде (Меззаде = "В")] 
риб11с АсЕ1опВези1® ботеАс®1олп () 
{ 
Везропзе.Икт®е ("Асезоп 1$ гипп1та"); 
хесаги Сопфепе ("Вези1е 15 кипп1поа"); 
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На заметку! По умолчанию компилятор С# не позволит размещать два экземпляра одного и того 
же типа атрибута в одном месте. Компиляция прервется с сообщением об ошибке Вир!сае 
‘ЗпомМеззаде’ аййЬще (Дублирование атрибута ЗномМеззасде). Чтобы обойти это ограни- 
чение, разрешите атрибуту фильтра иметь множество экземпляров, вставив непосредственно 
перед объявлением класса ЗпомМеззадедеек1ЪБиее следующую строку: 


[АБЕу1риее0заде (АКЕт1рисеТагдей$ .С1аз3 | АЕЕтарибеТагоеез .МебНоЯ, АТомМо1тер1е=Етгае) ] 


Показанный выше код сгенерирует следующий вывод (для ясности добавлен разрыв 
строки]: 

[ВеЕогеАсЕ1оп В] [ВеЕогедсЕ1оп А]АС®Топ 15 гапо1пта [АЕбегаАс®1от А] [АРсекАС&1оп В] 

[ВеЕогеВези1% В] [Вебогевезо А]Вези1® 1$ гипо1пт9 [АЕбегВези1Е А] [АЕбехВези& В] 


Как видите, механизм подобен стеку: все начинается с вызова ОпАсстопЕхесиЕ1па (), 
затем выполняется метод действия, после чего стек раскручивается вызова- 
ми ОпАсе1опЕхесиееа (} в противоположном порядке; то же самое происходит с 
ОпВези1ЕЕхесие1по () и ОпВезо1Ехесисеа (). 

Так получилось, что при запуске кода фильгр В был выбран первым, но это вовсе не 
обязательно, поскольку формально порядок элементов в стеке фильтра не определен, 
если только он не указан явно. Определенный порядок для стека фильгров устанавлива- 
ется присваиванием значения типа 10% свойству Огдег каждого фильгра (это свойство 
определено в базовом классе Р11екгАеск1риее]): 


[3ВоиМеззасе (Меззаде = "А", Огаег = 1)] 
[3ВоиМеззасе (Меззаде = "В", Огаехг = 2)] 
руЮю11с АсЕ1опВези1® ЗомедсЕ1ол () 
{ 
Везропзе.Мх1 ее ("АсЕ1Топ 1$ кипп1та"); 
хебигп СопЕеп® ("Везо1е 1$ гипп1па"); 


} 


Фильтры с меньшим значением Огдег идут первыми, поэтому на этот раз А и В по- 
являются в обратном порядке: 


[ВеЁогедАсЕ1от А] [ВебохеАс®1оп В]АсЕ1оп 1$ капп1па [АЕбехгАслоп В] [АЁбекАсе1оп А] 
[ВебогеВези1% А] [ВефохеВезо1{ В]Вези1е 1$ хипп1п9 [АЕбекВези В] [АЕсегВези1{ А] 


Все фильтры действий сортируются по Огдекг. Не имеет значения, какой тип фильг- 
ра они имеют или на каком уровне определены (на уровне действия, контроллера или 
базового класса контроллера) — фильтры с меныним значением Огдег всегда запус- 
каются первыми. Затем запускаются все фильтры результатов в порядке их значений 
Огаег. 

Если значение свойству Ог@ек явно не устанавливается, то такой фильгр остается 
“неупорядоченным” и по умолчанию получает специальное значение Ог@ег, равное -1. 
Поскольку явно присвоить значение меныше -1 нельзя, неупорядоченные фильтры все- 
гда выполняются первыми. Как было указано ранее. группы фильтров с одинаковым 
значением Огаег (например, неупорядоченные), запускаются в неопределенной после- 
довательности между собой". 


7 На практике фильтры, назначенные контроллерам, выполняются перед фильграми, назна- 
ченными методам действий. Кроме того, порядок определяется выводом метода рефлексии 
„МЕТ под названием сеесизботАСЕтарисез (), который используется внутренне для обнару- 
жения атрибутов фильтров. Этот метод может вернуть атрибуты в другом порядке, отлич- 
ном от указанного в исходном коде. 
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Использование контроллера в качестве фильтра 


Существует другой способ присоединения кода в качестве фильтра, не предусматри- 
вающий создание атрибутов. В самом базовом классе Сопего11ег есть реализации интер- 
фейсов ТАСЕ1о0пЕ11ек, ТВезо1ЕЕ116ег, ТАЛЕВохг12а1опЕ11$ег и Техеси 1опЕ1 ег. 
Это значит; что он представляет следующие переопределяемые методы: 


® ОпАСсЕ1топЕхесиетиа () 
® ОпАСстопЕхесиееа () 
® ОпВКези1ЕЕхеси®1ла () 
® ОпВези1ЕЕхесиееа () 
® ОпАСЕПоктхае1оп () 

® ОпЕхсереТол () 


За счет переопределения любого из них код будет запускаться именно в той точке 
конвейера обработки запроса, где и эквивалентный атрибут фильгра. Эти методы кон- 
троллера запускаются первыми, перед любыми атрибутами фильтра эквивалентного 
типа, независимо от свойств Огдег атрибутов. Данные методы предлагают очень быст- 
рый и легкий путь добавления кода контроллера, который выполняется перед или после 
всех методов действий определенного контроллера либо при возникновении необрабо- 
танных исключений в конкретном контроллере. 

Итак, когда стоит создавать и присоединять атрибут фильгра, а когда просто переоп- 
ределять методы фильтра базового класса СопЕго11ег? Ответ прост: если планируется 
повторно использовать поведение во множестве контроллеров, то фильтр лучите задать 
атрибутом. Если же он используется в одном специфическом контроллере, то лучше пе- 
реопределить один из перечисленных выше методов. 

Это также означает, что если создать общий базовый класс для всех контролле- 
ров, то можно будет применить код фильгра глобально ко всем контроллерам, просто 
переопределив метод фильтра в базовом классе. Это гибкий и мощный шаблон Гацег 
Зиретуре (супертип слоя). Платой за эту мощь может быть дополнительная сложность 
при долговременном сопровождении, так как слишком просто со временем добавлять 
все больше и больше кода к базовому классу, даже если этот код нужен только подмно- 
жеству контроллеров, и тогда все контроллеры становятся сложными и медленными в 
работе. Необходимо находить баланс между мощью этого подхода и эффективностью 
управления базовым классом. Во многих случаях безопаснее не применять шаблон 
Гауег Зиребуре, а вместо этого строить функциональность комбинированием соответ- 
ствующих атрибутов фильгра для каждого отдельного контроллера. 


Создание и использование фильтров авторизации 


Как упоминалось ранее, фильтры авторизации относятся к специальному типу 
фильтра, который запускается на ранней стадии конвейера обработки запросов, те. 
перед любыми последующими фильтрами действий, методами действий и результа- 
тами действий. Создать специальный фильтр авторизации можно, унаследовав его от 
Е11секАбсфк1риате или реализовав ТАПЕВог17еЕ116ек. Однако по причинам, которые 
объясняются чуть ниже, обычно лучите либо использовать встроенный конкретный 
фильтр авторизации АцЕНог1 ;еАЕЕк1риее, либо наследовать подкласс от него. 

Свойства класса АиЕНохг1 хеАеЕг1риее, которые можно устанавливать, перечислены 
в табл. 9.7. 
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Таблица 9.7. Свойства класса АзеЕНог1 хеАЕгаЬике 


Имя свойства Тип Назначение 


Огаег 106 Порядок выполнения этого фильтра по отношению к другим филыьт- 
рам авторизации. Меньшие значения идут первыми. Унаследовано 
от Р11секхдебг1рибе. 


Озегз 3Ек1п9 Разделенный запятыми список имен пользователей, которым разре- 
шен доступ к методу действия. 


Во1ев 36119 Разделенный запятыми список имен ролей. Чтобы получить доступ 
кметоду действий, пользователю должна принадлежать, по крайней 
мере, одна из этих ролей. 


Если устанавливаются оба свойства, О5егз и Во1ез, то пользователь должен удов- 
летворять обоим критериям, чтобы иметь доступ к методу действия. Например, если 
атрибут используется следующим образом: 


раю1с с1аз$ М1скозоЕЕСопеко Тек : Сопёко1Тек 

{ 
[Ацфнохг12е (Озегз="р111а9, зкеуерю, гауо", Во1ез="сра1утап, сео") ] 
раю11с АсЕ1опВези1Е Виубта1ТСотрапу (36 х1п4а сопрапуМате, дочю1е рг4се) 
{ 


// Поздравить с приобретением. 


} 


то пользователь может получить доступ к действию Виубпа11Сопрапу, если отвечает 
всем перечисленным ниже критериям. 


1. Пользователь аутентифицирован (те. НЕЕрСопеехе .Озег .Таепе1еу .ТзАисрепЕ1сасеа. 
равно Екие). 


2. Имя пользователя (те. несрСопеех® .Озек.Т4еп®1у.Маше) равно 61119, зЕеуер 
или гауо. 


3. Ему принадлежит, как минимум, одна из ролей сБа1гтап или сео (как определено 
НЕбрСопЕехе .Озек .ТзТиВоТ1е (го1еМапе) ). 


Если пользователь не отвечает хотя бы одному из этих критериев, то Ацевох12еАвск росе 
отменяет выполнение метода действия (и все последующие фильтры) и стимулирует вы- 
дачу кода состояния НТТР 401 (что означает “не авторизован”). Код состояния 401 ини- 
циирует систему аутентификации (Еогтз Аи ®епНсаНоп), которая может предложить 
пользователю войти в систему или же вернуть экран запрета доступа (ассезз детед). 

Если имена пользователей не указаны, то критерий 2 пропускается. Если не указа- 
ны имена ролей, то пропускается и критерий 3. 

Поскольку фильтр определяет имя и роль приславшего запрос пользователя, про- 
сматривая объект ТРг1пс1ра1 в НЕЕрСопфехе.0зек. он автоматически совместим с 
Еогп1$ Аи епйсаНоп, интегрированной системой УЛидао\з АшепНсаНоп и любыми 
другими специальными системами аутентификации/авторизации, которые уже уста- 
новили значение неерСоптехе .0зег. 


На заметку! Фильтр [АцЕвог1хе] не предоставляет возможности комбинировать критерии 2 и 3 
с помощью операции дизъюнкции (т.е. операции “или”, которая позволила бы пользователю по- 
лучать доступ к действию, если его регистрационным именем является ©1119 или ему принад- 
лежит роль спа1гщап или то и другое). Чтобы добиться такого поведения, потребуется реали- 
зовать специальный фильтр авторизации. Вскоре будет приведен соответствующий пример. 
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Взаимодействие фильтров авторизации с кэшированием вывода 


Очень скоро вы узнаете, что АЗРМЕТ МУС также поддерживает кэширование вывода 
через встроенный фильгр [ОиериЕСаспе]. Оно работает подобно кэшированию вывода 
АЗРМЕТ \/еБЕогиа$, в том отношении, что кэширует весь ответ, так что он может быть 
повторно использован немедленно при следующем запросе того же ОВГ. “За кулисами” 
фильтр [ОцЕри&Сасве] реализован на основе технологии кэширования ядра платфор- 
мы АЗРМЕЛ; а это означает, что если есть элемент кэша для определенного ОВ!, то он 
будет использован вместо вызова какой-либо части АЗРМЕТ МУС (даже без фильтров 
авторизации). 

Что же произойдет, если вы попробуете скомбинировать фильтр авторизации с 
[ОцЕериеСасВе]? В худшем случае вы рискуете тем, что если первый авторизованный 
пользователь посетит действие, вызвав его запуск и кэнтирование, а вскоре за ним к 
тому же действию обратится неавторизованный пользователь, то последний получит 
кэшированный вывод, даже не будучи авторизованным. К счастью, разработчики 
АЗРМЕТ МУС учли эту проблему и добавили специальную логику к Аапог1хеАеег1риее 
для правильной работы с кэшированием вывода АЗРМЕТ. Эта логика использует мало- 
известный АРГ-интерфейс кэширования вывода, чтобы зарегистрировать себя для за- 
пуска, когда модуль выходного кэширования собирается обработать ответ из кэша. Это 
предотвращает доступ неавторизованных пользователей к кэшированному содержимо- 
му. Причина объяснения этого запутанного поведения может быть на первый взгляд не 
ясна. Это сделано потому, что если вы реализуете с нуля собственный фильтр авториза- 
ции, наследуя его от Е11егАсег1риее и реализуя ТАЯЕВог1ха&1опЕ11тег, то не унас- 
ледуете этой специальной логики, а потому рискуете открыть доступ неавторизован- 
ным пользователям к получению кэшированного содержимого. Поэтому не реализуйте 
ТАНЕРог17а&1опЕ116ек непосредственно, а создавайте подкласс, унаследованный от 
АНЕВог1 хеАЕЕгарабе. 


Создание специального фильтра авторизации 


Как объяснялось ранее, лучший способ создать специальный фильтр авторизации — 
унаследовать подкласс от АаПог12еАеек1риее. Для этого потребуется переопределить 
виртуальный метод АцЕВог1теСоге() и вернуть значение роо1, указывающее, автори- 
зован ли пользователь. Например: 


роБ11с с1азз ЕпБапсеаАиВог1;еАЕк1риее : АиРог1теАеЕт1риее 
{ 
руЮюТ1с 6001 А1маузАТТом1оса1Веаиез{з = Ёа13е; 
ргобесфеа оуегг1ае БооЪ АиПог12теСоге (Зузфет. Иер .НЕЕрСопеех®Вазе ВЕЕрСопфех®.) 
{ 
1Е (А1маузА11омТоса1Веаиез®з && ВЕЕрСопеехе.Веааез®.Т$Тоса1) 
гегаки гие; 
// Вернуться к нормальному поведению [Аиц®Ког17е] 
гегигп Базе .АцеВок1теСоге (ВЕерСопфех®) ; 


} 
Специальный фильтр авторизации может использоваться следующим образом: 
[ЕпвапседАиВог1те (Во1ез = "ВепобеАди1т", А1ТмаузА1Томоса1Весаез®з = ©гие) ] 


Этот фильтр должен открыть доступ посетителям, если они принадлежат к роли 
ВетофеАаи1т или непосредственно зарегистрированы в системе УЯп4ом$ на самом 
сервере. Подобным образом удобно предоставлять администраторам сервера доступ к 
определенным функциям конфигурирования, не обязательно открывая доступ к ним 
через Интернет. 
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Поскольку атрибут унаследован от класса Е11ЕекАкЕк1рике, он наследует и свой- 
ство Огаег, поэтому можно задавать порядок его применения по отноптению к другим 
фильтрам. Стандартный объект АЗРМЕТ МУС по имени СопЕго11ехАсЕ1опТптуокек за- 
пустит каждый из них по порядку. Если любой из фильтров авторизации запрещает 
доступ, то Сопеко11екАсе1опТпуоКегк сокращает процесс, не пытаясь запускать после- 
дующие фильгры авторизации. 

Также из-за того, что класс унаследован от АиеВог1хеАеек1рите, он разделя- 
ет поведение, обеспечивающее безопасность кэширования вывода и применения 
НеЕрОпачеВог1теаВези1*, если в доступе отказано. 


Совет. Как было описано ранее, специальный код авторизации можно добавить в индивидуаль- 
ный класс контроллера, не создавая атрибут фильтра авторизации. Для этого нужно просто 
переопределить метод ОпАцЕПог1ха%1оп () контроллера. Чтобы запретить доступ, при- 
Свойте Е115ехСопеехе.Вези1& любое значение, отличное пи11, например, экземпляр 
НЕЕрОпацВог1 7хеЯВези1+. Метод ОпАсВог1хаезоп () запустится точно в той же точке 
конвейера обработки запросов, что и атрибут фильтра авторизации, и может решать те же са- 
мые задачи. Однако если логика авторизации должна разделяться между несколькими кон- 
троллерами или нужна безопасность кзширования вывода, то лучше реализовать авторизацию 
в виде подкласса АцВог1 теле к1Ьиее, как демонстрировалось в предыдущем примере. 


Создание и использование фильтров исключений 


В приведенном ранее псевдокоде было показано, что фильтры исключений запускают- 
ся только тогда, когда появляются необработанные исключения в процессе работы фильт- 
ров авторизации, фильтров действий, методов действий, фильтров результатов или самих 
резульгатов действий. Фильгры исключений используются в двух основных сценариях. 


® Для протоколирования исключения. 
® Для отображения пользователю соответствующего экрана с сообщением об оптибке. 


В нестандартных случаях можно реализовать специальный фильтр исключения, ав 
простых — использовать встроенный фильгр Напд1еЕгхкогАСЕ Е Ьихе. 


Использование фильтра Напа1еЕггогАЕЕГаЬиее 


Фильгр Напа1еЕгкогАЕ г1рисе позволяет обнаруживать специальные типы исклю- 
чений и после их обнаружения просто визуализировать определенный шаблон пред- 
ставления и установить код состояния НТТР в 500 (что означает “внутренняя ошибка 
сервера"). Основное его предназначение связано с отображением некоторого рода экра- 
на с сообщением о возникших проблемах. Он не протоколирует исключение — для этого 
потребуется создать специальный фильтр исключений. 

В классе НапаеЕккогАЕ к1рифе определены четыре свойства, которые перечисле- 
ны в табл. 9.8. 


Таблица 9.8. Свойства класса Нап91еЕткохгАЕЕу1Ьаке 


Имя свойства Тип Значение 

Огаех ое Порядок выполнения этого фильтра по отношению к другим фильт- 
рам исключений. Меньшие значения идут первыми. Унаследован от 
Е11текАСЕг1раее. 

=хсер1опТуре Туре Фильтр обработает этот тип исключений (и унаследованные от него 


типы) и проигнорирует все прочие. Значением по умолчанию явля- 
ется Зузеем. Ехсере1оп, означающее, что по умолчанию будут 
обрабатываться все исключения. 
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Окончание табл. 9.8 


Имя свойства Тип Значение 


Утем 57119 Имя шаблона представления, который этот фильтр визуализирует. 
Если значение не указано, то по умолчанию оно равно Етгох, 
что приводит к визуализации страницы 
/У1емз/имяТекущегоКонтроллера/Еггог.азрх или 
/У1еиз/ЗВагеЯ/Егког.азрх. 


Мазфетх ЗЕ119 Имя мастер-страницы, используемой для визуализации шаблона 
представления. Если значение не указано, представление использу- 
ет свою мастер-страницу по умолчанию. 


Предположим для примера, что этот фильтр применяется так, как показано ниже: 


[Напа1ТеЕггохг (Узеи = "РеоБ1ет") ] 
РиБ11с сфазз Ехапр1еСопеко11ек : Сопеко11ек 
{ 

/* ... методы действий ... */ 


} 


В таком случае, если во время запуска любого метода действия (или ассоциирован- 
ного фильтра) на этом контроллере возникнет исключение, то Нап91еЕкгогАЕ Е г1Бике 
попытается визуализировать представление из одного из перечисленных мест: 


1. -/У1еиз/Ехапр1е/Ркор1ей.азрх 
2. -/М1емз/Ехаптр1е/Ркою1епт.азсх 
3. -/У1емз/5рагеа/РкоБ1ей.азрх 
4. -/У1емз/5ВагеЯ/Ргор1ет.азсх 


На заметку! Фильтр Напа1еЕгкогАс с к1Бифе оказывает действие только тогда, если в файле 
мер . сопЕ1а включен режим обработки специальных ошибок. Для этого в узел <зузфещ.меб> 
следует добавить элемент <сизботЕггогз тоае="Оп" />. По умолчанию устанавлива- 
ется режим специальных ошибок ВетосеОрТу, при котором во время разработки фильтр 
Нап91еЕкгогАЕ Е г1раее не перехватывает исключения вообще, а делает это только после 
того, как приложение развернуто на рабочем сервере, и начинают поступать запросы с другого 
компьютера. Во избежание сложностей, установите режим обработки специальных ошибок в Оп. 


При визуализации представления фильтр Напа1еЕхкокАЕ Е к1Бисе предоставляет 
объект Моае1 типа Напа1еЕггогТоЕо. Поэтому, если сделать шаблон представления 
обработки оптибок строго типизированным (указав Напа1еЕгкогТоЕо в качестве типа 
модели), появится возможность обращаться и визуализировать информацию об исклю- 
чении. Номестим для примера следующий код в /У1емз/5Кагеа/РгоБ1ет.азрх: 


$@ Раде Гапдцаде="С+#" ТиБеглЕз="бузвет. Иер .Мус .\У1еиРаде<Напд1еЕ гкокТпЕо>" %> 
<!РОСТУРЕ НЕюшф РОВЬТС "-//ИЗС//ОТО ХНТМЬ 1.0 ТкапзтЕ1опа1Ъ//ЕМ" 
"ВЕЕр://мим. м3 .оха/ТВ/хНемт1 /РТЬ/хЬет11-Ехапз11опа1.969"> 
<ВетТ хш1п5="ВЕЕр://мими.м3.0Е9/1999/хрЕшт" > 
<Веа@ кипа =“зегуех"> 
<Е101е>богку, Етеге иаз а ркоБ1ет! </51Е1е> 
</пеа9> 
<роду> 
<р> 
ТНеге маз а 
<р><$%= Н&п1.Епсоде (Моде1 .ЕхсерЕ1оп.бееТуре () .Маше) %></ь> 
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ур11е гепаег1па 
<Ь><%= НЕт1 .Епсодае (Моае1 .СопЕго11ехгМаие) $%></6>'!5 
<Ь><$%= НЕи1.Епсоде (Моае1.АсефопМаце) %></ь> асЕлоп. 
</р> 
<р> 
Тне ехсерЕ1оп пшеззаде 15: 
<Ь><%= НЫ] .Епсоде (Моде1 .Ехсер1оп.Меззаае) %></Ъ> 
</р> 
<р>5фаск Егасе:</р> 
<рге><%= Не] .Епсодае (Моде1.ЕхсерЕ1оп.бЕаскТгасе) %></рге> 
</Боау> 
</пет1> 


В резульгате будет отображен экран, подобный показанному на рис. 9.7. Естественно, 
на публично доступном веб-сайте вряд ли стоит предоставлять на общее обозрение ин- 
формацию подобного рода (особенно содержимое стека), но во время разработки она 
будет полезной. 


© 


= Зону, Вере из; а риа егий - оиеглеЕ Екротег 


Тнеге эгаз а Ри4деВуРегоЕхсернон НШе тенденле Еег5Вешо’ ЗоньеАсНон асбов_ 


а варим. 


| 

В „ ТВе ехсернон шеззаяе 15: Анешруей 1о йе Бу гего. 
В ы 

| 

| 


| ИИ” 


Рис. 9.7. Визуализация представления из Напа1еЕ ггогАЕЕЕ1ЬиЕе 


Когда фильтр Напа1еЕтхогАЕЕ к1роее обрабатывает исключение и отображает пред- 
ставление, он помечает исключение как обработанное, устанавливая свойство по имени 
Ехсер*1опНапа1еа в с гие. Назначение и смысл зтого действия станут ясными в сле- 
дующем примере. 


Создание специального фильтра исключения 


Как и следовало ожидать, можно создать специальный фильтр исключений, построив 
класс, унаследованный от Е11{ехАбег1роее и реализующий ТехсерЕ1орЕ1 1 ег. Один 
из подходов состоит в том, чтобы просто протоколировать исключение в базе данных 
или в журнале событий приложений УЛпдо\з и поручить другому фильтру генерацию 
видимого вывода для пользователя. Другой подход предполагает генерацию видимого 
вывода (те. визуализацию представления или перенаправление) за счет присваивания 
объекта АсЕ1опВези1* свойству Е11%егСопеехе .Ве511+. Ниже показан пример специ- 
ального фильтра исключений, который осуществляет перенаправление: 


руЮ11с с1азз Вед1гесЕОпЕгкохАеЕк1ЮиЕе : Е11кегАЕЕгариее, ТЕхсерЕ1опЕ11 ег 
{ 
ру11с уола опЕхсерЕ1оп (ЕхсерЕ1опСопеехЕ Е11ЕегСопеехе) 
{ 
// Не вмешиваться, если исключение уже обработано 
1Е (Е: 1 ЕегСопЕехЕ .Ехсер®1опНапа1еа) 
гебагп; 
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// Уведомить следующий запрос о том, что что-то пошло не так 
Е11тегСореехе .СопЕго11ет .Тепррафа["ехсере1оп"] = Е11тегСопфехе .Ехсер® 1оп; 


// Установить перенаправление к глобальному обработчику ошибок 
Е11сегСопеехЕ.Везо1Е = пем Вед1тес®Товопеекези1+ (пем КоифеУа1аер1с®1опахгу ( 
рем { сопего11ет = "Ехсер1оп", асЕ1оп = "Напа1еЕттог" } 


)); 


// Посоветовать последующим фильтрам исключений не вмешиваться, 
// и предотвратить выдачу "желтого экрана смерти" АЗР.МЕТ 
Е11теуСопеехе .Ехсере1опНапа1ея = %гие; 


// Удалить сгенерированный вывод 
Е1]1тегСопеехЕ .НЕЕрСопЕехе .Везропзе.С1еахг (); 


} 


В зтом примере демонстрируется применение Е11+ехСопеехе .Ехсер®*1опНапа1Теа. 
Это свойство типа Боо1, которое изначально равно Еа1зе, однако по мере запуска 
фильтров исключений один из них может переключить его в Егце. Это. однако, не за- 
ставит СопЕхо11етАсЕ1опТпуокег прекратить запускать последующие фильтры исклю- 
чений. Он все равно выполнит все оставшиеся фильгры исключений, что удобно, если 
какие-то из них должны протоколироваль исключения“. 

Флаг Е11{егСопфех+ .Ехсер+1опНапЯ1е@ сообщает последующим фильграм исклю- 
чений, что вы позаботились обо всем, позтому они могут игнорировать данное исключе- 
ние. Однако зто не принуждает их игнорировать исключение: они могут все равно про- 
токолировать его, и даже переопределить #11 егСопеехе .Вези1е. Встроенный фильтр 
НапЯ1еЕттохАЕЕг1риее ведет себя корректно: если Е11{ехСопеехе .Ехсере1опНапа1еа 
уже установлен в гие, он полностью игнорирует исключение. 

После того, как все фильтры исключений запущены, СопЕхо11егАсЕ1опТпуокег по 
умолчанию проверяет Е11ЕегСопфехЕ .Ехсер1опНапа1еа, чтобы узнать, считается ли 
исключение обработанным. Если оно все еще равно Еа1зе, то исключение будет пере- 
дано в среду АЗРМЕТ, что приведет к знакомому “желтому экрану смерти” (если только 
не был установлен глобальный обработчик исключений АЗРМЕТ}. 


Совет. Как было описано ранее, специальный код обработки исключений можно поместить в ин- 
дивидуальный класс контроллера, не создавая атрибутов фильтра исключений, а просто пе- 
реопределяя вместо этого метод контроллера опЕхсерелоп (). Этот код будет запускаться 
в той же точке конвейера обработки запросов, что и атрибут фильтра исключений, и может 
выполнять ту же работу. Если не планируется разделять код обработки исключений с другими 
контроллерами, то такой подход заметно проще. 


Распространение исключений по фильтрам 
действий и результатов 


Фильтры исключений не являются единственным средством для перехвата и обра- 
ботки исключений. 


® Если метод действия генерирует необработанное исключение. то методы 
ОПАСЕ1опЕхесифеа () всех фильтров действий также будут запущены, и любой из 
них может пометить исключение как обработанное, установив Е11егСопфехе. 
Ехсере1опНапа1еа в { гие. 


8 Как будет показано в следующем разделе, поведение изменяется. если исключение будет 
помечено как обработанное фильтром действий или фильгром результатов: это не позволит 
последующим фильграм даже увидеть это исключение. 
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® Если результат действия генерирует необработанное исключение, то все методы 
ОпВезо1+ЕхесикеЯ () фильтров результатов также будут запущены, и любой из 
них может пометить исключение как обработанное, установив Е11$егСопеехе. 
Ехсер®1опНапа1еа в Е гие. 


Чтобы прояснить работу этого процесса и понять, почему методы ОпАСсЕ1опЕхесиееа () 
запускаются в порядке, противоположном ОпАсЕ1опЕхесие1пта(), взгляните на 
рис. 9.8. На нем видно, что каждый фильтр в цепочке создает дополнительный уровень 
рекурсии. 


Фильтр действия 1 ОпАсНопЕхеси по) „>| ОпАсвопЕхесиед0 
ЖЖ ПО СОЕД О о еиниснызаИй # 
У 
Фильтр действия 2 ОпАсНопЕхесипо() еее ОпАсНопЕхесие9() 
Фильтр действия 3 ОпАсбопЕхесийта( |: ОпАсНопЕхесшев0 |? 


Рис. 9.8. Рекурсивный вызов фильтров действия из метода действия 


Когда на любом уровне возникает исключение, оно перехватывается на уровне выше, 
причем вызывается ОпАсЕ1опЕхесиееа () этого уровня. Если ОпАсЕ1опЕхесиееа() ус- 
танавливает Е11ЕегСопеех® .ЕхсерЕ1опНапа1еа в Е гие, то исключение поглонтается, 
и никакой другой фильтр его больше не увидит (в том числе и фильтры исключений). 
В противном случае оно генерируется повторно и перехватывается на следующем уров- 
не, расположенном выше. В конечном итоге, если самый верхний фильтр действия 
(те. первый) не помечает исключение как обработанное, то будут вызваны фильтры 
исключений. 

Точно такая же последовательность событий происходит при обработке фильгров 
результатов и результатов действий. Исключения распространяются вверх по вызовам 
ОпВези1+Ехесифеа() почти так же, будучи поглощенными или отправленными даль- 
ше. Если верхний (те. первый) фильтр результата не помечает исключение как обрабо- 
танное, вызываются фильгры исключений. 

Как упоминалось ранее, если исключение достигает фильтров исключений, то за- 
пускаются все фильтры исключений. И если в конце окажется, что ни один из них не 
пометил исключение как обработанное, то исключение генерируется повторно в самом 
АЗРМЕТ, что может привести к появлению “желтого экрана смерти” или отображению 
специальной страницы с сообщением об ошибке. 


Скрытая подробность 


Если вам когда-либо приходилось изучать внутреннее устройство механизмов прежних версий 
АЗРМЕТ, то вы должны знать, что при перенаправлении с использованием Кезропзе .Ве1геск () 
выполнение может быть остановлено с генерацией исключения ТьгеаЯдАБогЕЕХсерЕ1 оп. 
В случае вызова Везропзе .ВеЯ1гес* () вместо возврата соответствующего объекта 
Веа1гесеТоВези1+ из АЗР.МЕТ М\УС) может показаться, что зто приведет к ненужному сра- 
батыванию фильтров исключений. К счастью, разработчики М\УС предвидели зту потенциальную 
проблему и обеспечили трактовку исключения ТьгеаЯАБохЕЕхсерЕ1оп как особого случая. 
Исключения этого типа скрыты от всех фильтров, так что перенаправления не будут восприни- 
мать его как ошибку. 
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Фильтр действия [ОцЕраЕСасве] 


Несложно догадаться, что фильтр Опера СаснедАЕЕг1Ьиее заставляет АЗРМЕТ кэ- 
пгировать вывод метода действия. так что один и тот же вывод будет повторно исполь- 
зоваться при следующем запросе того же метода действия. В результате пропускная 
способность сервера повышается на несколько порядков, поскольку повторяющиеся 
запросы исключают почти все дорогостоящие части обработки (вроде обращений к 
базе данных). Конечно, зто дается ценой неизменности вывода в ответ на каждый такой 
запрос. 

Как и средство кзширования вывода ядра АЗРМЕТ, встроенный в АЗРМЕТ МУС 
фильтр ОпероеСасведеег1риее позволяет задавать набор параметров. которые ука- 
зывают, когда следует варьировать вывод действий. Это компромисс между гибкостью 
(изменение вывода) и производительностью (повторное использование предварительно 


кэшированного вывода). 
Параметры ОпЕриЕСасведЕег1Ьиее перечислены в табл. 9.9. 


Таблица 9.9. Параметры фильтра ОпЕриЕСасьедАЕЕхЬаке 


Имя параметра Тип Значение 

Рига оп 10 Насколько долго (в секундах) вывод остается 

(обязательный) кэшированным. 

УагувВуРагат ЗЕг1па Заставляет АЗРМЕТ использовать другой элемент 

(обязательный) (список, разделенный — кэша для каждой комбинации значений Веачезх . 
точкой с запятой} Онегу5г1ипоа и Ведцез® .Еогт, совпадающих с эти- 

ми именами. Можно также использовать специальное 
значение попе, которое означает “не варьировать по 
значениям строки запроса или формы”, или *, что зна- 
чит “варьировать по всем значениям строки запроса и 
формы”. Если не указано ничего, по умолчанию прини- 
мается попе. 

УагуВунеааег Ве Заставляет АЗРМЕТ использовать разные элементы 
(список, разделенный — кэша для каждой комбинации значений, присланных в 
точкой с запятой} НИР-заголовках с этими именами. 

УагуВуСозЕ ом ЗЕт1п9 Произвольная строка. Если указана, АЗРМЕТ вызывает 
метод сесУагуВуСиЕот5Ет1птоа (} из с1офа1. 
азах . сз с этой строкой в качестве параметра, так 
что можно предоставить произвольный ключ кэша. 
Специальное значение Бгомзехт служит для варьирова- 
ния кэша по имени браузера и старшему номеру версии. 

УатуВуСопеепЕЕтсоа 119 — зку1па Позволяет АЗРМЕТ создавать отдельный элемент кэша 


Тоса Топ 


(список, разделенный 
точкой с запятой} 


ОперисСасвеГгосае1оп 


для каждой кодировки содержимого (например, 9215, 
4еЕ1ахе), которую может запросить браузер. О коди- 
ровании содержимого речь пойдет в главе 15. 


Одно из следующих перечислимых значений, специ- 
фицирующих, где будет кэширован вывод: зегуег 
(только в памяти сервера), С11епЕ (только в браузере 
посетителя), Роипзегеам (в браузере посетителя или 
любом промежуточном устройстве НТТР-кэширования, 
таком как прокси-сервер), зегуегАпаСс1 1еп (комби- 
нация Зегуег и С11еп*), Апу (комбинация Зегуег И 
Роипбегеам), Мопе (без кэширования). Если не указа- 
но, принимается значение по умолчанию Апу. 
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Окончание табл. 9.9 


Имя параметра Тип Значение 


Мо5Еоге ©о01 Если равно © гие, посылает в браузер заголовок 
Сасве-Сопего1: по-збоге, инструктируя его не 
хранить (те. не кэшировать) страницу дольше, чем не- 
обходимо для ее отображения. Если посетитель позднее 
вернется к странице, щелкнув на кнопке Назад в брау- 
зере, это значит, что браузер должен повторно отправить 
запрос, что сказывается на производительности. Это ис- 
пользуется только для защиты конфиденциальных данных. 


СасверРтоЕ11е ЗЕг1п9 Если указан, инструктирует АЗРМЕТ извлечь настройки 
кэша из определенным образом именованного узла 
<соцериЕСаспезеЕЕ1п43$> в ме. сопЕ1с. 


за1Ререпдепсу зег1п9 Если указывается пара имен базы данных и таблицы, это 
заставляет кэш устаревать автоматически при измене- 
нии информации базы данных. Перед тем, как это зара- 
ботает, потребуется также сконфигурировать средство 
АЗРМЕТ $С1 Саспе Оерепдепсу, что является довольно 
сложным процессом, рассмотрение которого выходит 
за рамки настоящей книги. Подробную документацию 
ищите по адресу Веер: //мзап .мескозоЕе . сот/ 
ги-го/11Ьтагу/тз178604.азрх. 


Огдег 10 Унаслелован от Е1 1сехАЕЕк1Ьоте, но не является важ- 
ным, потому что ОцпероеСасведАсЕт1Бсхе дает одина- 
ковый эффект независимо от того, когда он запущен. 


Если вы ранее пользовались средством кэширования вывода АЗРМЕТ, то эти опции 
должны быть знакомы. Фактически фильгр ОпероеСаснедеЕг1Биее — это просто оболоч- 
ка вокруг основного средства кэширования вывода АЗРМЕТ. По этой причине он всегда. 
варьирует элемент кэша согласно пути ОВЕ. При наличии параметров в шаблоне ОРГ. ка- 
ждая комбинация значений параметров вызывает обращение к разным элементам кэпта. 


Внимание! В разделе “Взаимодействие фильтров авторизации с кэшированием вывода” ранее 
в главе объяснялось, что [АпВог1=е] имеет специальное поведение, гарантирующее, что 
неавторизованные посетители не смогут получить важную информацию из кэша. Однако если 
специально не предотвратить это, то остается возможность, что кэшированный вывод будет 
предоставлен другому авторизованному пользователю, отличному от того, для которого он 
изначально был предназначен. Один из способов предотвратить зто состоит в реализации 
собственного управления доступом к определенному элементу содержимого в виде фильт- 
ра авторизации (унаследованного от АцЕВог12еАЕЕг1Ьоее) вместо простого принуди- 
тельного применения логики авторизации, встроенной в метод действия, потому что фильт- 
ру АрЕНог1хеАЕЕг1расе известно, как избежать его обхода при кэшировании вывода. 
Тщательно выполняйте тестирование, чтобы гарантировать, что авторизация и кэширование 
вывода взаимодействуют ожидаемым образом. 


Внимание! Из-за деталей внутренней реализации встроенный фильтр [ОцЕроеСасве] не со- 
вместим со вспомогательным методом НЕм1.ВеплЧегАсЕ1оп (). Можете показаться, что 
[ОцЕриЕСасве] будет кэшировать вывод только того графического элемента, который визуали- 
зируется с помощью Нет1 .ВепдегАсЕТоп () ‚ но на самом деле зто не так — он всегда кэширует 
вывод всего запроса. Чтобы исправить зто несоответствие, загрузите альтернативный фильтр 
кзширования вывода из блога автора по адресу Неер: //Е1пуит1 . сощ/мусОпериоеСасвВе. 
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Другие встроенные фильтры 


В состав АЗР.МЕТ МУС входят еще два готовых к использованию фильтра: 
Уа11ЧафеТпра{ и Уа11ЧаЕ1опАпЕ1ЕогдекуТокКеп. Оба они являются фильтрами авто- 
ризации, относящимися к безопасности, и рассматриваются в главе 13. 


Контроллеры как часть конвейера 
обработки запросов 


Взгляните на рис. 9.9. На нем показана часть конвейера обработки запросов МУС, 
где запросы сначала отображаются системой маршрутизации на определенный кон- 
троллер, а затем зтот контроллер выбирает и вызывает один из своих методов действий. 
К настоящему моменту эта последовательность должна выглядеть достаточно знакомо. 


Запрос Ответ 


Маршрутизация Метод действия 


Фабрика Средство 
контроллеров вывован 
действий 
Использует данные Использует данные 
маршрутизации маршрутизации 
‚для выбора и создания ‚для выбора и 
экземпляра контроллера вызова действия 


Рис. 9.9. Процесс вызова метода действия 


Как известно, по умолчанию в АЗРМЕТ МУС для выбора контроллеров и действий 
используют соглашения. 


® Если Бопеерафа.Уа1тез ["сопЁго11ех"] равно Ргодисез, то фабрика контрол- 
леров по умолчанию, РеЕап1ЕСопЕго11егРасфоху, будет искать класс контрол- 
лера по имени Ргодисе $Сопего11егк. 


® Базовый класс контроллера поумолчанию использует компонент СопЕго11ехАсЕ1оп 
Тиуокег для выбора и вызова метода действия. Если Воптерахта .\а1пез ["асе1оп"] 
равно Г15%, то СопЕхо11ехАсЕ1оптиуокег будет искаль метод действия по имени 
115 {). 


Во многих приложениях это работает достаточно хорошо. Но неудивительно, что МУС 
предоставляет возможность при желании настраивать или заменять эти механизмы. 

В этом разделе будет показано, как реализовать специальную фабрику контроллеров 
или встроить специальную логику выбора действия. Наиболее вероятной причиной для 
этого является необходимость подключения контейнера инверсии управления (ТоС) или 
блокировка доступа определенных типов запросов к некоторым методам действий. 


Работа с РеЕаз1ЕСопЕго11ехЕас*огку 


Если не установлена специальная фабрика контроллеров, то по умолчанию будет ис- 
пользоваться экземпляр РеЕап1СопЕго11егРасфогу. Внутренне он хранит кэш всех 
типов сборок АЗР.МЕТ МУС, на которые ссылается проект (и не только в самом проекте 
АЗРМЕТ МУС). Эти типы квалифицируются как классы контроллеров в соответствии со 
следующими критериями. 
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® Класс должен быть помечен как раБ11с. 

® Класс должен быть конкретным (те. не помеченным как аъ згас\). 
® Класс не должен принимать обобщенных параметров. 

® Имя класса должно оканчиваться строкой СорЕго11ет. 

® Класс должен реализовать интерфейс ТСопЕго11ег. 


Для каждого типа, удовлетворяющего этим критериям, Беёап1ЕСопЕго11етгРасфогу 
добавляет ссылку на него в кэше. помеченную маршрутным именем типа (те. име- 
нем типа с удаленным суффиксом СопЕго11ег). При запросе создания зкземпляра 
контроллера, соответствующего определенному маршрутному имени (поскольку оно 
указано в Копеерафа .\Уа10ез ["сопЕго11ех"]), РеЕац1ЕСопЕго11етКасфкогу может 
очень быстро найти этот тип по ключу. После выбора типа контроллера его экземн- 
ляр создается вызовом АсЕ1уафог .СгеафеТпзфапсе (типКонтроллера)} (вот почему 
РеРа1ЕСопЕтго11егЕасфеогу не может обрабатывать контролеры, конструкторы кото- 
рых требуют параметров) и возвращается результат 

Сложности возникают, когда нескольким классам контроллеров назначаются 
одинаковые имена, даже если они находятся в разных пространствах имен. Тогда 
РеЁач1 ЕСопЕго11етГасбоку не знает, экземнляр какого класса необходимо создать, 
и просто генерирует исключение 1пуа11ЯО0регаЕ1опЕхсерЕ1оп, означающее “ТЬе 
сопгоЦег пате 15 атЫвцочз” (неоднозначное имя контроллера). Чтобы справиться с 
этим, понадобится либо избегать создания нескольких контроллеров с одинаковыми 
именами, либо обеспечить для РеРаз1ЕСопего11егЕасфеогу какой-нибудь способ уста- 
новки приоритетов одних классов над другими. Для определения порядка приоритетов 
предусмотрено два механизма. 


Глобальное назначение приоритетов пространствам 
имен с использованием РеЕаи1ТЕМатезрасез 


Чтобы заставить РеЁаз1+СопЕго11егЕасфогу отдавать предпочтение классам 
контроллеров, определенным в некоторых коллекциях пространств имен, необхо- 
димо поместить соответствующие значения в статическую коллекцию по имени 
СопЕго11ехВи11Аег.СиггепЕе.БеЕаз1ЕМамезрасез. 

Например, добавьте в файл С1ора1.азах.сз следующие строки кода: 


ргофесфеа уо1а Арр11саЕ1оп баке () 
{ 
Вед1зЕегВоцеез (ВоифеТаь1е.Воитез); 
Сопфго11ехВи11дег .Сагкепе.РеЕао1ЕМатезрасез Ааа ("МуАрр .Сопего11егз"); 
Сопего13етВи11дег. Сихгеп+ .РеЕаз1+Мапезрасез .Ада ("ОЕВетАззепЬ1у .ЗотеМапезрасе") ; 
} 


Теперь, если имя желаемого контроллера уникально для одного типа контроллера 
внутри зтих пространств имен, то РеРаз1ЕСопЕго11егРасеогу выберет и использует 
зтот тип контроллера вместо генерации исключения. Однако если внутри этих про- 
странств имен все равно присутствует несколько подходящих типов контроллеров с од- 
ним и тем же именем, исключение Тпуа11Ч9Орега1опЕхсерЕ1оп снова будет сгенери- 
ровано. (Не следует впадать в заблуждение, думая, что приоритеты пространствам имен 
в РеЁац1 ЕМапезрасез назначаются согласно порядку их добавления в эту коллекцию; 
этот порядок не имеет значения.) 

Если Берат ЕСопЕго11ехРасфогу не может найти ни одного подходящего типа кон- 
троллера в перечисленных пространслвах имен, он возвращается к своему обычному пове- 
дению и выбирает тип контроллера из любого места независимо от пространства имен. 
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Назначение приоритетов пространствам имен 
по индивидуальным элементам маршрута 


Приоритеты для пространств имен можно также назначить и для использования 
при обработке определенного элемента ВосееТар1е .Воиеез. Предположим, например, 
что шаблон ОВГ. ато / { сопего11ех} / {асЕ1оп} при выборе контроллера должен отда- 
вать предпочтение пространству имен МуАрр .Ади1ит .СопЕго11ег5, игнорируя осталь- 
ные пространства имен с идентично именованными контроллерами. 

Чтобы реализовать такое поведение, добавьте к элементу маршрута значение 
РафаТокепз под названием Мацезрасез. Добавленное значение должно реализовывать 
интерфейс ТЕпомегар1е<з&г1пс>: 


тооЕез.Ада (пем Воцте ("аЧи1п/ {сопЕго11ек}/{асЕ1оп}", пем МусВосфеНапа1ек ()) 
{ 
РеЁап1Е$ = пем КоцеУа1ер1сЕ1опагу (пем { 
сопего11ег = "Ноше", асЕ1оп = "Тоаех" 
}), 
ГафаТокКепз = пен ВоцееУа1аер1се1опаку (пем { 
Матезрасез = пеи[] { "МуАрр.Адт1п .Сопеко11егз", 
"АпоеВегАззетЪ Ту .Сопего11егз" } 
}) 
}); 


Приоритеты для этих пространств имен будут устанавливаться только во время за- 
просов, соответсчвующих данному элементу маршрута. Сами зти приоритеты имеют 
преимущество перед СопЕго11етВи114ег.Сиггепе.реЕап1ЕМатезрасев. 

Если вместо объектов Восее используются специальные подклассы ВоцееВазе, в них 
также можно обеспечить назначение приоритетов пространствам имен контроллеров. 
Например, в коде метода Сесвоцеерака () поместите значение ТЕпомега1е<зЕг1пд> в 
возвращаемую объектом Воцеераба коллекцию РафаТокепз: 


ру611с с1а5з СазфошВоцее : ВоиееВазе 
{ 
раБ11с оуегг14е Воиферафа сесвоцеерата (НЕЕрСопеехЕВазе НЕЕрСопеехЕ) 
{ 
1Е (выбор для сопоставления с этим запросом) 
{ 
Бочферафа га = пем Воикерафа (13, пем МусВоптенапа1ет()); 
та.Уа1иез ["сопЕго11ег"] = выбранный контроллер 
га. Уа10ез ["ас1оп"] = выбранное имя метода действия 
га.рРафаТокепз ["пашезрасез"] = пем[] { "МуАрр .Адт1п .Сопего11етз" }; 
хебиги га; 
} 
е1зе 
тесагп пи11; 
} 
РУБ11с оуегг1@е У1гЕаа1Ра®ЮРака сеЕ\У1геиа1РаеВ(...} { /*и и... */ } 
} 


Создание специальной фабрики контроллеров 


Если простой готовый класс РеЁао1ЕСопего11ехЕаскоку не устраивает, можно за- 
менить его собственным специальным. Наиболее очевидная причиной для этого явля- 
ется желание создавать экземпляры объектов контроллеров через контейнер 1оС. Это 
позволило бы передавать параметры конструкторам контроллеров на основе конфигу- 
рации ТоС. Пример использования ЮС приведен в главе 3. 
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Специальную фабрику контроллеров можно создать, либо написав класс, реализуютций 
интерфейс тСопего11ег, либо унаследовав подкласс от РеРац1ЕСопЕго11егРГас®оху. 
Последний вариант обычно более продуктивен, поскольку он позволяет унаследовать 
болыпую часть функциональности по умолчанию (вроде кэптирования и быстрого на- 
хождения любого типа, на который ссылается проект) и просто переопределить поведе- 
ние, которое должно быть изменено. 

В табл. 9.10 перечислены методы, которые могут быть переопределены в случае на- 
следования от ПеЁа11ЕСоп{го11етРас®охгу. 


Таблица 9.10. Переопределяемые методы класса РеЕаз1СопЕхго11ехЕас®оку 


Метод Назначение Поведение по умолчанию 
СтеаеСопеко11ет ( Возвращает экземпляр кон- Вызывает сесСопего11етТуре () и 
тедиезСопеехе, троллера, соответствующий затем передает возвращенное значение 
сопЕго11егМапе) переданным параметрам. СесСопЕго11етТизфапсе (). 
СеЕСопего11етТуре ( Выбирает тип .МЕТ, на основе — Ищеттип контроллера, чье маршрутное 
сопЕго11етМаще} которого должен быть создан = имя (имя без суффикса СопЕхо11ег) 
экземпляр контроллера. равно сопЕго11етгМаме; подчиняется 
описанным ранее правилам назначение 
приоритетов. 
бессопегоЛетТиз‹апсе( — Возвращает актуальный Вызывает АсЕ1уабох .СтеабеТпзкапсе ( 
сопего11етТуре) экземпляр указанного типа. сопЕго11ектТуре). 
Ве1еазеСопего1 Тег ( Выполняет необходимую Если контроллер реализует интерфейс 
сопего1Тег) очистку. 101 зрозаю1е, вызывает его метод 
21 зрозе (). 


Для интеграции с болыпинством контейнеров оС необходимо лишь переопределить 
СеЕСопЕго11екТпзфапсе (). Логику выбора типа и очистки по умолчанию можно не из- 
менять, так что остается очень мало работы, которую придется выполнить. В главе 4 
рассматривался простой пример создания экземпляров контроллеров через контейнер 
1оС под названием Саз@е УЛлазог. 


Регистрация специальной фабрики контроллеров 


Для использования специальной фабрики контроллеров необходимо зарегистриро- 
вать ее экземпляр в статическом объекте СопЕго11егВи114етг.Сиггепе. Это должно 
делаться лишь однажды, на ранней стадии жизни приложения. Например, добавьте 
следующий код в С1офа1.азах.сз: 


рготесфеЯ \хо1@Я Арр11саЕ1оп 5фаге () 
{ 
Вед1зЕегВоцеез (КоцфеТаБ1е.Бойез); 
СопЕго11егВи114ег.Сиггепе.беЕСопего11егЕас®огу (пеи МуСопегоехЕас®огу()); 
} 


Это и вся регистрация. 


Настройка выбора и вызова методов действий 


Вы только что узнали, каким образом каркас МУС выбирает класс контроллера, кото- 
рый должен обрабатывать входящий запрос, и как можно изменить зту логику за счет реа- 
лизации собственной фабрики контроллеров. Это отображено в левой половине рис. 9.9. 
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Теперь перейдем к правой половине рис. 9.9. Каким образом базовый класс контрол- 
леров Зузеем. Мер .Мус .СопЕго11ег выбирает метод действия, который нужно вызвать, 
и как встраивать специальную логику в этот пропесс? Сейчас вы узнаете о том, что 
действие и метод действия — в действительности не одно и то же. 


Реальное определение действия 


До сих пор все определяемые действия были методами С#, и имя каждого действия 
всегда соответствовало имени метода С#. По болышей части именно так они и работают, 
но на самом деле все несколько тоньше. 

Строго говоря, действие — это именованная часть функциональности контроллера. 
Эта функциональность может быть реализована в виде метода контроллера (и обычно 
так и есть) или же каким-то иным образом. Имя действия может соответствовать име- 
ни метода, который реализует его (обычно так и есть}, или же может отличаться. 

Каким образом метод контроллера становится действием? Если вы создадите кон- 
троллер, унаследованный от базового класса контроллера, то каждый из его методов 
считается действием, если отвечает следующим критериям. 


® Он должен быть помечен как роБ11с и не помечен как зкафлс. 


®_ Он не должен быть определен в Зузеем. Мер .Мус.Сопего11ех или в любом дру- 
гом его базовом классе (сюда относятся ТобЕт1по (), СеЕНазНСоае{) итн.). 


® Онне должен иметь “специального” имени (как определено флагом 155рес1а1Маце 
в 5узсем .ВеЕ1ес(1оп .МеЕпоЯВазе). Это исключает, например, конструкторы и 
методы доступа к свойствам и событиям. 


На заметку! Методы, принимающие обобщенные параметры (например, Мумеепоа<т> (} ), счи- 
таются действиями, но при попытке вызова одного из них будет просто сгенерировано 
исключение. 


Использование [АсЕ1опМате] для указания 
специального имени действия 


Как уже утверждалось, действие представляет собой именованную часть функцио- 
нальности контроллера. Обычное соглашение МУС Егатзе\огК гласит. что имя дейст- 
вия берется из имени метода, который определяет и реализует его функциональность. 
Обойти это соглашение можно, используя АсЕ1опМамедлеетарике, например: 


[Асе1опМаше ("ргобис*з-115%") ] 
руБ11с АсЕ1опВези1Е Р1зр1ауРгодисЕ $113 () 


При конфигурации маршрутизации по умолчанию вы не найдете это действие в 
обычном ОВ. /имяКонтроллера/01зр1ауРгодиасез [1 зе. Вместо этого ОВТ, будет выгля- 
деть как /имяКонтроллера/ргодис*-113+. 

Это дает возможность применения имен действий, которые недопустимы в качестве 
имен методов С#, как в предыдущем примере. Можно использовать любую строку, ко- 
торая допустима в качестве части ОВГ.. Другой причиной является необходимость соз- 
дания методов действий, имена которых подчиняются определенным соглашениям, но 
применение в ОВ! других соглашений. 
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На заметку! Теперь должно быть понятно, почему обобщенные вспомогательные методы гене- 
рации ЦВЕ из состава МУС Рщиге$ (наподобие Нл1 .Асезоптаюк<т> () }, которые генерируют 
УВЕ просто из имен „МЕТ, не имеют смысла и не всегда работают. Именно потому они не вклю- 
чены в основной комплект М\С Егатемогк. 


Выбор метода С# по его возможности обрабатывать запрос 


Иногда имеется несколько методов С#, являющихся кандидатами на обработку од- 
ного имени действия. Возможно, есть несколько одноименных методов (принимающих 
разные параметры), или вы используете [АсЕ1опМапе], поэтому несколько методов 
отображаются на одно и то же имя действия. При таком сценарии платформе МУС 
ЕгашемогК необходим механизм для выбора между ними. 

Этот механизм называется селектором метода действия и реализуется через класс 
атрибута под названием АсЕ1опМеево95е1есвогАе& глрофе. Ранее уже использовался 
один из подклассов этого атрибута — Ассер\УехозАкариее. Этот подкласс предот- 
вращает обработку методом действия запросов, которые не соответствуют назначенно- 
му методу НТТР. Например: 


[Ассере\Уетьз (НЕбрУетЬз .сеф) 1] 


руЮ1+с АсЕ1опВезо1е РобопеЕЬ1та() { ... } 
[АссереУеткЬз (НЕЕрУетЬз.Роз®) ] 
рУБ11с АСЕ1опКеза1е РобомеЕеь1па (1пЕ зомеРагат) { ... } 


Здесь присутствует только одно логическое действие по имени Робопеев1па. 
Существуют два разных метода С#, которые могут реализовать это действие, и выбор 
между ними для каждого запроса производится по-своему, согласно входящему методу 
НТТР Подобно всем прочим атрибутам селектора метода, АссереУетозАеЕтг1 роке унас- 
ледован от АсстопМеепоа5е1есеокАЕг1Ьоее. 


На заметку! Атрибуты селектора метода могут выглядеть похожими на атрибуты фильтра (по- 
скольку оба они являются типами атрибутов}, но на самом деле они совершенно не имеют 
отношения к фильтрам. Взгляните на конвейер обработки запросов: выбор метода должен про- 
исходить в начале, потому что набор применяемых фильтров не известен до тех пор, пока не 
будет выбран метод действия. 


Создание специального атрибута селектора метода действия 


Создать специальный атрибут селектора метода действия несложно. Просто унаследуй- 
те новый класс от АсетопмМекрод5е1ескохАеег1риоке и переопределите его единственный 
метод Т5Уа119ЕогВесиезе (). возвращая Е гае или Ёа1 зе, в зависимости от того, должен 
ли метод принять запрос. Ниже показан пример реализации атрибута обработки или иг- 
норирования запросов в зависимости от входящей схемы (например, Вр или ВЕЕрз]}: 


роь11с с1азз Ассеребсремедееу1роее : АсЕ1опмМеевоа$ е1есвохАеЕг1раее 
{ 
рУБ11с АссеребсВемеде Е т1Ьоте (5Ег4па зсВепе) { 
Зсвеше = зсрепе; 
} 
роБ11с зЕхг1поа бсреше { дее; рхг1уабе зе(; } 
ру611с оуегк1ае Боо1 Тз\/а119ЕогВеааез® (Сопеко11етСопеехЕе соп®го11етСопеехе, 
МеЕпоаТоЕо шеероЯаТпЕо) 


уаг асЕпа1$сВетме = соп&хо11ехСоп®ехе .НЕЕрСопеехе .ВКеааезе.0г1.осрепе; 
гебогп аскиа1$ свете .Ела1$ (5сБете, 5Ех1п9Сотраг1зопт .Ог1па1ТопогеСазе); 
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Этот агрибут можно использовать для реализации разного поведения в зависимости 
от того, поступил запрос по 55Е или нет. Например: 


[Ассеребсвеме ("ВЕфрз") 1 

[АсЕ1опМапе ("Сеебепз1Е1уеТоРогиа1оп") ] 

ри611с АСЕ1ТопВези1е сеЕбепз1Е1уеТоРогпа&1оп_НТТР$(}) { /* Запускается для 
запроса НТТРЗ */ } 

[Ассере5сВепе ("БЕфр") ] 

[АСЕ1опМапе ("Сбеебепз11уеТоРогнаЕ1оп") 1 

рчЬ11с АсЕ1опВезо1е сее5еп1Е1уеТпРогта®1оп_НТТР () { /* Запускается пля 
запроса НТТР */ } 


Совет. Как известно всем программистам С#, методы класса полжны иметь разные имена либо, 
как минимум, разные наборы параметров. Это неудобное ограничение для АЗРМЕТ МУС, так 
как в предыдущем примере было бы больше смысла, чтобы два метода действия имели одина- 
ковые имена и отличались лишь атрибутами [АссерЕ5свеме1. Это одно из нескольких мест, гле 
основательное использование АЗРМЕТ М\УС рефлексии и метапрограммирования выходит за 
рамки того, что изначально планировали проектировщики .МЕТ Ргатемогк. В данном примере 
зто легко обходится применением [АсЕ1опМаме]. 


Идея селектора метода состоит в выборе между несколькими методами, которые мо- 
гут обработать одно логическое действие. Не путайте это с авторизацией. Если цель 
состоит в том, чтобы разрептить или запретить доступ к одиночному действию, приме- 
няйте фильтр авторизации. Формально атрибут селектора метода можно использовать 
для реализации логики авторизации. но это будет не лучший способ выражения наме- 
рений. Это не только запутает других разработчиков. но приведет к странному поведе- 
нию, когда авторизация не проходит (возвращая оптибку “404 Моё Коип@” вместо воз- 
врата на зкран входа в систему). Вдобавок нарушится совместимость с кэшированием 
вывода, как обсуждалось ранее в этой главе. 


Использование атрибута [МопАсЕ1 оп] 


Помимо АсЕ1опМамеАеек1 росе, в МУС Егате\мотК имеется еще один готовый ат- 
рибут селектора метода МопАсЕ1опАеек1Ьоее. Он чрезвычайно прост: его метод 
Тз\а110РогВесиез® () просто каждый раз возвращает Еа15е. В следующем примере с 
его помощью запрещается запуск Мумеевоа() в качестве метода действия: 


[МопАСЕ1оп] 
риб11с уо1а МуМеевоа () 
{ 


} 


Зачем это может понадобиться? Вспомните, что общедоступные методы экземпляра 
в классах контроллеров могут вызываться непосредственно из Веб кем угодно. Если в 
контроллер необходимо добавить общедоступный метод, который не должен быть от- 
крыт для доступа из Веб, то из соображений безопасности его следует пометить с по- 
мощью [МопАСЕ1оп]. 

Это редко может понадобиться, потому что с точки зрения архитектуры обычно кон- 
троллерам не имеет смысла раскрывать общедоступные средства другим частям прило- 
жения. Как правило, каждый контроллер должен быть самодостаточным, а общедоступ- 
ные средства должны предоставляться моделью предметной области или какой-нибудь 
рода библиотекой служебных классов. 
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Работа всего процесса выбора методов 


Вы уже видели, что выбор компонентом Сопёго11ехАс®1опТшуокех метода действия 
зависит от широкого диапазона критериев, включая входящее значение Воскерака. 
Уа10ез ["асЕ1оп"], имена методов контроллера, атрибуты [АсЕ1опМаме] этих методов 
и их агрибуты выбора методов. 


Чтобы понять, как все это работает вместе, рассмотрим диаграмму, представленную 
на рис. 9.10. 


Необходимо найти метод, 
соответствующий конкретному 


методу действия Находит все методы, соответствующие 


запрашиваемому имени действия. 
Методы относятся к одному из двух типов. 


- Методы без псевдонимов (не имеющие атрибута [Ас&1опМаме ] ). 
Эти методы включаются в список, если их имя совпадает с 
методов-кандидатов запрашиваемым именем действия (без учета регистра символов}. 


- Методы с псевдонимами (имеющие атрибут [Ас 1опМаме]). 
Эти методы включаются в список, если значение их атрибута 
[АсЕ1 опМапе ] совпадает с запрашиваемым именем действия 
(без учета регистра символов). 


Получить список 


Отбросить всех кандидатов, 
у которых атрибут 
АСсЕ1опМесвоабе1есеогАЕ Е г1Бае 
возвращает Еа1зе 


Сколько 
кандидатов имеют 
хотя бы один атрибут 
АсЕ1опМмМесводзе1есеох 
Абегтросе? 


Один 
Использовать этот метод 


Исключение! 


Много 


Неоднозначное соответствие. 


Ноль 


Один Использовать этот метод 


Запустить обработчик 


Сколько всего 
кандидатов? 


Много неизвестного действия 


Ноль 


Запустить неизвестный 


обработчик действия 


Рис. 9.10. Выбор компонентом СопЕхо11ехАсЕ1опТпуокКег метода для вызова 


Обратите внимание, что если метод имеет несколько атрибутов селектора метода, 
то они все должны соответствовать запросу, иначе метод не будет включен в список 
кандидатов. 

На рис. 9.10 также видно, что МУС Егате\хогК отдает предпочтение методам с ат- 
рибутами селектора (подобными [АссереУетьз1). Такие методы считаются в болыпей 
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мере соответствующими, чем обычные методы, не имеющие атрибута селектора. Каков 
смысл этого соглашения? Это значит, что следующий код не приведет у генерации ис- 
ключения из-за неоднозначного соответствия: 


роь11с АсЕ1опБезо1е МуАсЕ1опт () {... } 


[АссереУетьз (НесрУетЬз .Роз®) ] 
рур11с АсЕ1опВезо1Е МуАсЕ1 оп (МуМоде1 поае1) { ... } 


Несмотря на то что оба метода предназначены для обработки запросов РОЗТ, ат- 
рибут селектора метода имеет только второй метод. Поэтому ему и будет отдано пред- 
почтение в обработке запросов РОЗТ, а первый метод должен будет обрабатывать за- 
просы всех прочих типов. Однако вместо того, чтобы полагаться на эти малоизвестные 
соглашения о приоритетах, имеет смысл применить к обоим методам действий селектор 
[АссерУегрЮз5], что значительно облегчит понимание кода с первого взгляда. 


р 
Скрытая подробность 


Если вас действительно не заботят подробности выбора метолов, можете проигнорировать зту 
врезку. При построении списка методов-кандидатов МУС ЕгатемогК считает, что метод имеет лсев- 
доним, если с ним связан любой атрибут, унаследованный от Асе1 опМамезе1ессокАекароке 
{не путайте его с АсЕ1опмеепод5елескотАеек1 роке). Теоретически можно было бы создать 
специальный класс АсЕ1опМапезе1ескогАсек1 Роке и затем использовать его для динами- 
ческого изменения имени метода действия во время выполнения. Большинство разработчи- 
ков обычно так не поступают, поэтому предыдущее обсуждение было несколько упрощено за 
счет предположения, что [АсЕ1опМаме] является единственно возможным атрибутом типа 
АсЕ1опМаме5е]1есбокАеетг1рике. Для большинства зто упрощение вполне оправдано, так как 
зто единственный встроенный тип АсЕ1опМамее1есеогАеЕг1роке. 


Обработка неизвестных действий 


Как показано на рис. 9.10, если не находится методов, соответствующих опреде- 
ленному методу действия, то базовый класс контроллера по умолчанию попытается 
запустить обработчик неизвестного действия. Это виртуальный метод. имеющий имя 
Напа1е0пкпомпАсЕТол (). По умолчанию он возвращает ответ “404 Мо Коипа” (не най- 
дено)}, но его можно переопределить, например, так: 


руЮ11с с1азз НотеСопетго11ег : Сопего11егк 
{ 
ркофесфеа оуегк14е уо1Я Напд1е0пкКпочпАсЕ1 оп (зЕг1па асЕ1опМаме) 
{ 
Кезропзе.Ик1ее ("Уой аге Еку1па 60 кип ап асЕ1оп са11еа " 
+ Зегуек.НЕм1Епсоае (асЕ1опМапе))}; // Вывод сообщения о попытке 
// запуска неизвестного действия 


} 


Если теперь запросить ОВ. /Нопе/АпуВ1па, то вместо ошибки “404 Моё Еоипа” бу- 
дет получено следующее сообщение: 


Усц аге Егу1тач со гоп ап асЕ1оп са11еа АпуЕЬ1па 


Это одно из многих мест. где АЗРМЕТ МУС предлагает возможность расширения, 
поэтому можно делать практически все, что угодно. Однако по перечисленным ниже 
причинам в данном случае зто не то, что нужно делать часто. 
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® НапО1е0пкпомпАс®1от () не является наилучигим способом получения произ- 
вольного параметра из ОНТ. (как в предыдущем примере). Для этого предназна- 
чена система маршрутизации! Параметры маршрутизации в фигурных скобках 
намного более выразительны и мощны. 


® Если вы собираетесь переопределить Напа] е0пКпомпАсЕ1опт () ,‚ чтобы сгенериро- 
вать собственную страницу ошибки “404. Мог Еойп@”, то не торопитесь, посколь- 
ку есть лучший способ. По умолчанию метод Напд1е0пКпомтАс&1оп () базового 
класса контроллера вызовет средство специальной ошибки ядра АЗРМЕТ. За до- 
полнительными деталями о конфигурировании специальных ошибок обращай- 
тесь к документации МЗОМ по адресу ВЕЕр: //Е1пуит1 .сом/азрпее404. 


Тестирование контроллеров и действий 


Многие части платформы МУС ЕгашехогК специально спроектированы для под- 
держания тестируемости. Это особенно верно в отношении контроллеров и действий, 
вдобавок важно, поскольку зто ключевые строительные блоки приложения. Так что же 
делает их подходящими для модульного тестирования? 


е Их можно запускать вне контекста веб-сервера (например. в графической сре- 
де МОп!). Причина в том, что они обращаются к объектам контекста (Ведоез(, 
Везропзе, $е551оп и т д.} только через абстрактные базовые классы (например, 
НЕЕрБедие5%Вазе, НЕ&р5езз1оп5{афеВазе), которые можно имитировать. Они 
не связаны напрямую с конкретными реализациями традиционного АЗР.МЕТ 
(НЕЕрВедоез%, НЕЕр5езз1оп5еа®е), которые работают только в контексте веб- 
сервера. (По той же самой причине вне контекста веб-сервера нельзя запускать 
страницы АЗРМЕТ` \/’еЪЕогилз.} 


® Не требуется синтаксический разбор какой-либо НТМГ-разметки. Для того что- 
бы проверить корректность вывода, производимого контроллером, необходимо 
просто выяснить, какой шаблон представления был выбран, и какие значения 
У1енрака и Моде1 переданы. Все зто становится возможным благодаря строгому 
разделению между контроллерами и представлениями. 


е Обычно даже не придется применять имитации или тестовые дубли объектов 
контекста, потому что привязка параметров устанавливает “шов тестируемости” 
между кодом и объектом Ведиез+*, а система резульгатов действий помещает ана- 
логичный “шов тестируемости” между кодом и объектом Везропзе. 


Если проведение модульного тестирования своего приложения не планируется, 
то изложенные выше факты могут показаться не особенно существенными. Однако 
на практике вы обнаружите естественную связь между тестируемым кодом и кодом с 
ясной архитектурой. Тщательно продуманная тестируемость АЗРМЕТ МУС стимули- 
рует аккуратное разделение ответственности, и это окупается, когда дело доходит до 
сопровождения. 

Для написания модульных тестов не обязательно быть профессионалом в области 
разработки, управляемой тестами. Просто гюпробуйте! Да, поначалу это трудно®, но на- 
личие подходящего комплекта тестов превратит ваш код в основу для построения более 
надежных решений, выделяя те проектные решения, которые были недостаточно про- 
думаны, и почти неизбежно приведет к более аккуратной архитектуре. 


9 Писать тесты не всегда трудно, гораздо труднее помнить о том, что их нужно писать. 
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Подготовка, выполнение и утверждение в модульном тесте 


Чтобы модульные тесты получались осмысленными и легкими для понимания. мно- 
гие разработчики следуют шаблону А/А/Л (аггапбе/ас!/аззег — подготовка/действие/ 
утверждение). Сначала выполняется подготовка набора объектов, описывающих неко- 
торый сценарий, затем производится действие над ними и, наконец, осуществляется 
проверка утверждения о получении желаемого результата. Такой подход легко перено- 
сится на тестирование контроллеров МУС. 


1. Подготовка. Создание экземпляра объекта контроллера (в сценариях ТоС конст- 
руктору могут передаваться имитированные версии любых зависимостей). 


2. Действие. Запуск метода действия с передачей ему простых параметров и полу- 
чение АсЕ1опВези1. 


3. Утверждение. Проверка того, что Асе1опВези1* описывает ожидаемый резульгат 


Имитировать или создавать тестовые дубли для объектов контекста (например, 
Ведиез®, Кезропзе, ТетрРата и тп.) необходимо только в случаях, если контроллер об- 
ращается к любому из них напрямую. К счастью, это случается не часто. 


Тестирование выбора представления и У1емра+а 


Ниже показан код предельно простого контроллера: 


рур11с с1аз$ 54ир1еСопЕхко11ех : Сопеко11ег 
{ 
рур11с У1емВези1* Тпаех () 


{ 
тебакп \У1ем ("МууУ1ем"); 
} 


С помощью МОпЕ можно проверить, визуализирует ли Тпаех() желаемое представ- 
ление: 


На заметку! Описание настройки МИпИ и создания проекта тестов ТезЕз дается в сносках 
“Тестирование” главы 4. В частности, для проекта ТезЕ5 понадобятся ссылки на сборки 
Зузеет.Мер.Мус, Зузсет. Мер .Вопе1па, Зузкет.Меь.АБзЕкас®1опз, а также на сам 
тестируемый проект АЗРМЕТ МУС МеБ АррИсаНоп. 


[ТезеЕ1хеите] 
рур11с с1азз 51ир1еСопЕго11егТезез 
{ 
[ТезЕ] 
руБ11с ухота Тпдех Вепдегз Му\1еч () 
{ 
// Подготовка 
31тр1еСопЕко11ех сопехо11ек = пен $1пр1еСопего11ег (); 


// Действие 
\У1еиВези1% гези1е = сопЕко11ег.Тпаех (); 


// Утверждение 
Аззеге. ТзМоЕ№11 (гезо1е, "Р1а поЕ гепдег а у1еи"); 

// Визуализация представления не выполняется 
Аззеге.АгеЕсаа1 ("Му\у1еи", гези1е.У1еиМаце); 
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Имейте в виду, что когда метод действия визуализирует свое представление по умол- 
чанию (просто вызывая гебокп У1фем()), значением У1емМаше будет пустая строка. 
В этом случае последний вызов Аззеге нужно переписать следующим образом: 


Аззеке .ТзЕтреу (хези1е.\У1е\Мапе); 


Тестирование значений У1зеъраЕа 
Если в методе действия используется структура У1емРаба, например: 


руБ11с У1еиВезо1е ЗВомАчде (РафеТ1ие ю1кЕБраке) 
{ 


// Вычислить возраст в полных годах 

Рафетлме пом = Расет1ме .М№\м; 

10Е аде = пои.Уеаг - Б1уЕПРафе.Уеаг; 

ТЕ ( (пом.МопЕв*100 + пои.Бау) < (р1кЕБрабе .Мопеь*100 + Б1гЕРрафе.РВау)) 
аде -= 1; // Дня рождения в зтом году ете не было 

\У1емрафа ["аде"] = аде; 

хееакп У1еи(); 


} 
то можно протестировать также и ее содержимое: 


[Тезе] 
рур11с уо1а Р1зр1ауз_ Аде 6 ИШеп_Вогп 51х Уеаг5 Тио_Рауз_Ачдо() 


{ 


// Подготовка 

З1ир1еСопего11ехг сопЕго11етг = пеи 51ир1еСопЕго11ехк(); 

РасеТ1те р1кЕПрафе = РафеТ1те .Мои.АдаУеат5 (-6) .АЧарауз (-2); 

// Действие 

У1еиВезо1® гези1е = сопёго11ег.бПомАде (р1кЕБРа®е); 

// Утверждение 

Аззеке. ТэзМо №111 (тезо16, "Р1а по® гепаег а у1ем"); 

Аззеке. ТзЕпрЪу (хеза16.У1еиМапте); 

АззегЕ.АгеЕсаа1 (6, гези1+.\У1емПафа["аде"], "ЗВом1па мгопд аде"); 

// Неверный возраст 

} 


Если метод действия передает представлению строго типизированный объект 
Моде], то модульный тест может обнаружить это значение в гези1{ .\1еирафа.Моде!1. 
Обратите внимание. что гези1& .У1емПафа.Моае]1 имеет тип обес, поэтому потребу- 
ется выполнить приведение к предполагаемому типу модели. 


Тестирование перенаправления 


Если есть метод действий, который выполняет перенаправления, например: 


руБ11с Вед1гесЕТоКоскевез11е Вед1 з&егЕохОрдаеез (зЕг1пд ета11Адагезз) 
{ 
1Е (1!15\/а11АЕта11 (ета1ТАЯЯгезз)) // Реализуйте это где-нибудь 
гебогп Вед1кесеТоАсЕ1от ("ВКед1з%ег"); 
е1зе 
{ 
// ТОРО: Здесь выполнить регистрацию 
тесигп ВеЯ1кесеТоАсЕ1оп ("Вед1зЕхаЕ1опСопр1еееа") ; 
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то можно протестировать значения в результирующем объекте Веа1гесеТовонеевезо1: 


[Тез] 
рор11с уо1А Ассерез роь_аЁ ехашр1е Чо сом() 


{ 


} 


// Подготовка 
5Е:1п4 ема11 = "Борвехапр1е.сом"; 
31тр1еСопЕхко11ех сопёго11ег = пеи 5$1тр1еСопего11ек(); 


// Действие 
Веа1гесЕТовоцееВези1е гези1е = сопёго11ех.Вед1 зкегЕогОрдатез (епа11); 


// Утверждение 
Аззете . Т5МоЕМо11 (уези1%, "Р1ап'Е регЕоги а гед1геск1от"); 

// Перенаправление не выполняется 
Аззехге.АхеЕсоа1 ("Вед1зЕхаЕ1опСомрлефеЯ", гези1+.БоибеУа1иез ["асф1оп"]); 


[Тез] 
руЮ11с уо1а Ведесез в1ав() 


{ 


// Подготовка 
$ир1еСопехо11ех сопоко11ег = пем Зипр1еСопЕко11ек(); 


// Действие 
Веа1гесеТовонсевези1{ гези1е = сопего11ег.Вед1з$егКогОрдакез ("Б1ав"); 


// Утверждение 
Аззеге . Т5МоЕМ№ 11 (хези1е, "Р1ап’Е рекРоги а гед1лгес®1от"); 
Аззеге.АгеЕаоа1 ("Кед15фег", хези1.ВРоцфкеУа1щез ["ас®1оп"]); 


Дополнительные комментарии по поводу тестирования 


Теперь вам должно быть ясно, как проводить тестирование для другого типа 
АсЕ1опВези1*. Просто придерживайтесь шаблона А/А/А — он все расставит по мес- 
там. Поскольку все довольно очевидно. специфические примеры для других типов 
Ас 1опВез91* приводиться не будут. 

Если метод действия возвращает общий АсЕ1опВези1* (вместо специализирован- 
ного типа вроде \1еиВез01*), тест должен выпоннить приведение зтого объекта к ожи- 
даемому специализированному типу, а потом проверить утверждения относительно его 
свойств. Если специализированный тип Ас&1орВе501 может варьироваться согласно 
параметрам или контексту, можно написать отдельный тест для каждого сценария. 


На заметку! Имейте в виду, что при вызове метода действия вручную, как в предылущих примерах 
модульных тестов, он не запускает никаких фильтров, которые могут быть ассоциированы с 
методом или его контроллером. В конце концов, зти фильтры — просто атрибуты .МЕТ; они не 
имеют значения для самой платформы „МЕТ Ргатемогк. Некоторых разработчиков зто не уст- 
раивает, и они ищут способ запускать фильтры внутри модульных тестов. Однако это привело 
бы к утере смысла! Общая идея фильтров состоит в их независимости от действий, к которым 
они применяются. Именно зто делает фильтры многократно используемыми. При модульном 
тестировании методы действий должны проверяться как изолированные единицы, без тес- 
тирования одновременно всей инфраструктуры, которая окружает их во время выполнения. 
Фильтры также могут тестироваться в изоляции (независимо от любого конкретного метода 
действия). Для зтого понадобится написать отдельные модульные тесты, напрямую вызываю- 
щие методы фильтров, таких как ОпАсЕ1орЕхеси&1п9 () или ОпАс®1опЕхесиееа (). 
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Имитация объектов контекста 


В некоторых случаях методы действий работают не только с параметрами методов 
и значениями АсЕ1опВезо1*, а получают прямой доступ к объектам контекста. В этом 
нет ничего плохого (именно для того и нужны объекты контекста), но это означает не- 
обходимость в создании тестовых дублей или имитаций объектов контекста во время 
проведения модульного тестирования. В предыдущей главе при тестировании маршру- 
тов уже был показан пример, в котором использовались тестовые дубли. На этот раз мы 
сосредоточим внимание исключительно на имитациях. 

Рассмотрим следующий метод действия. В нем объекты Весаез+, Везроп$ и Соок1е 
используются для изменения поведения в зависимости от того, посещал ли ранее сайт 
данный посетитель. 


руБ11с У1емВези1е Нопераде ()} 
{ 
1Е (Вечиез®.Сооклез ["Наз\У1з16еЯВеЁоге"] == пи11) 
{ 
\У1емрафа["ТзЕ1тг56\У1$16"] = 6хое; 
// Установить соокме-набор, чтобы вспомнить данного посетителя в следующий раз 
Кезропзе.Соок1ез.Аяа (пем НЕЕрСоок1е ("Наз\У1 з1{еЯВеЁоге", 6оо1.Тгое8Ех1п9)); 
} 
е1зе 
У1еирака ["ТзЕ1х$6\1516"] = Еа]1зе; 
гебокп \У1ем(); 


} 


Это очень неясный метод, поскольку он полагается на массу внешних объектов кон- 
текста. Для его тестирования понадобится настроить рабочие значения зтих контекстных 
объектов. К. счастью, зто можно сделать с помощью любого инструмента имитации. Ниже 
приведен один возможный тест, написанный с использованием инструмента Мод. На 
первый взгляд он выглядит сложным. но не волнуйтесь — очень скоро все прояснится. 


[Тезе] 
роь11с уо1@ Нотераде_Весодп1тез Мем \1516ог Апа Зеёз_Соок1е () 
{ 
// Подготовка: сначала подготовить некоторые имитирующие объекты контекста 
уаг поскСопеехе = пем Моа.Моск<НеЕрСопеехЕВазе> (); 
уаг поскВедаезЕ = пем Моа.Моск<НЕЕрВеацез®Вазе> (); 
уаг поскВезропзе = пем Моа.Моск<НЕЕрВезропзеВазе> (); 


// В следующих строках определяются ассоциации между разными имитирующими объектами 
// (т.е. указывается, какое значение использовать для поскСопбехе.Ведоезе в Моа) 
поскСопеехеЕ. Зекир (х => х.Ведоезе) .Вебоги$ (посквеаоезе.ОБ)ес®); 
поскСопеехе .Зебир(х => х.Везропзе) .Вебогпз (поскВезропзе.ОБ]ес®); 
поскВеаоез® .бебир(х => х.Соок1ез) .Вебикиз (пем НЕЕрСоок1еСо11есЕ1оп()); 
посКкВезропзе .5ебор (х => х.СооК1ез) .Вееигкпз$ (пем НЕЕрСоок1еСо11есЕ1от ())}; 
уахг сопЕго11ег = пем 51ир1еСопего11ет (); 
уаг гс = пеи Ведоез®Сопеех® (поскСопеехе .ОБ]есе, пем Косферака ()); 
сопЕго11ег.Сопего1Т1егСопЕехе = пеи Сопего11ехСопеехЕ (хс, сопего11ет); 
// действие 
\У1еиВези1Е геза1е = сопехо]11ег.Нопераче (); 
// Утверждение 
Аззехке. ТзЕтреу (гезо1 .У\У1емМапе); 
Аззеге.ТзТкие ( (6001) гезо1® .\У1емафа ["ТзЕ1г3\У1516"1); 
Аззеге.АкеЕада1 (1, сопего11ехг.Везропзе.Соок1ез.Соипе); 
Аззеге.АгеЕсоа1 (6001 .Ткиебет1 пс, 

сопЕго11ег.Везропзе.Соок1ез ["Наз\У131ЕеВеЁЕоге"] .Уа1ще); 
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На заметку! Если вы пользуетесь версией Мод, предшествующей 3.0, вместо Зерир придется 
записать Ехресе. 


Тщательно рассмотрев приведенный выше код, вы увидите, что в нем устанавлива- 
ется имитирующий экземпляр НЕЕрСопеехЕ наряду с дочерними объектами контекста 
Веччез®, Везропзе и тд., а также утверждается, что сооме-набор Наз\У151еаВеЕоге 
должен быть отправлен в ответе. Однако масса подготовительного кода затеняет назна- 
чение теста, отнимает слишком много времени на написание, а также требует помнить, 
каким образом устанавливаются имитации. Давайте попробуем решить проблему ими- 
тации объектов контекста раз и навсегда. 


Многократно используемый служебный класс имитации А$Р.МЕТ МУС 


Логика, необходимая для имитации контекста времени выполнения АЗРМЕТ МУС, 
часто выносится в отдельный модуль, который можно повторно использовать во мно- 
жестве тестов. В резульгате отдельные модульные тесты можно существенно упростить. 
Для этого с помощью АРГинтерфейса выбранного инструмента имитации потребует- 
ся определить НЕЕрСопеехе, Весддез®е. Везропзе и другие объекты контекста, а также 
отношения между ними. В случае инструмента Мод вся эта работа делается с приве- 
денном ниже многократно используемом служебном классе (который входит в состав 
загружаемого кода для книги}: 


}9Ю11с с1азз СопеехЕМоск$ 
{ 
рур11с Моа.Моск<НЕЕрСопеехеВазе> НЕЕрСоптехЕ { деё; рглуаке зе(; } 
руБ11с Моа.Моск<НеерВеаиезВазе> Вечаезе { дес; рг1уафе зе; } 
руБ11с Моа.Моск<НЕЕрвезропзеВазе> Везропзе { де; ргауате зеф; } 
руб11с Вообера®а Воцеераба { деф; рглууафе зе; } 
руЮ11с СопеехЕМосКз (Сопехго11ег опСопЕко11ег) 
{ 
// Определить все общие объекты контекста и отношения между ними 
нсёрСоптехеЕ = пеи Моа.Моск<НнЕерСопкех(Вазе>(); 
ВедоаезЕ = пем Моа.Моск<НЕЕрвеаиез®Вазе> (}; 
Везропзе = пеи Моа.Моск<НЕЕркезропзеВазе> (); 
НЕЕрСопеех®е.Зебор (х => х.Веацезе) .Вебигиз (Ведиезе.ОБЗес®); 
НЕЕрСоптсехе .бегор(х => х.Везропзе) .Вебигпз (Везропзе.053ес®); 
НЕЕрСопсехе .Зебор (х => х.5езз1оп) .Вебиагп$ (пем РГаКебезз1опбаке()); 
Веаоез® .Зебир (х => х.СооКк1ез) .Вебигпз (пеи НЕЕрСоок1еСо11есезов ()); 
Везропзе.бебор (х => х.Соок1ез) .Вебикпз (пем НЕЕрСоок1еСо11есЕ1ов ())}; 
Веоиез® .бебор(х => х.Оцегу5Ег1п9) .Вегигпз (пем МамеУа1аеСо11есе1оп()); 
Веацезе .Зебар(х => х.Гогт) .Вебигпз (пем МатеУа1иеСо11есезот ()); 


// Применить имитирующий контекст к указанному экземпляру контекста 
ВеаиезеСопеехе кс = пеи ВедцезСопеех® (НЕЕрСопеех®.ОЮ]есе, пеи Вопферака())}; 
опсСопЕхго11ег.Сопекго11екСопеехе = пеи СопЕко11егСопеЕехе (гс, опСопго11ег); 
} 
// Использовать фиктивный НЕЕрбезз1оп$афеВазе, 
// потому что его трудно имитировать с помощью Моа 
рглуафе с1азз ЕГакебезз1оп5{аке : НЕбрзезз1оп5ЕакеВазе 
{ 
21сЕ1опаку<зЕт1ич, обесЕ> Шетз = пем РасЕ1опагу<эЕх1па, обЗесе> (); 
раб11с оуегг14е обдесе 113 [зЕт1па папе] 
{ 
чее { гкебогкп 1$етз.Сопба1пзКеу (папе) ? 16епз [папе] : по11; } 
зеё { 1(етз[паме] = уа1ае; } 
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На заметку! Этот вспомогательный тестовый класс подготавливает работающие реализации не 
только объектов Весдоез®е, Везропзе и их сооКе-коллекций, но также их свойств 5езз1оп, 
Вечаезе .Опегубетг1па и Ведцезе .Еогт. (Тетрраса также входит в ихчисло, потому что ба- 
зовый класс Соптго1 Тег устанавливает его, используя безз1оп.) Данный класс можно дополни- 
тельно расширить, добавив имитации для Весоезе .Неадетгз, НЕЕрСоптехе.Арр11са®1оп, 
НЕЕрСопеехе . СасВе, и использовать его многократно во всех тестах контроллеров. 


За счет использования служебного класса СопеехЕМоскз предыдущие модульные 
тесты можно упростить, как показано ниже: 


[ТезЕ] 
рур11с уо1а Номераде Весодт1тез_Меи \131фох_Апа 5еез_СооК1е () 
{ 
// Подготовка 
уак сопёго11ек = пем 5$1пр1ТеСопеко11ек(); 
уаг поскз = пем СопеехЕМоскКз (сопЕго11етх); // Настроить полный 
// имитирующий контекст 


// Действие 
У1еВезо1е гези1 = сопЕгхо11ег.Нопераде (); 


// Утверждение 

Аззеке.ТзЕпрсу (гези1е .У1еиМапе); 

Аззеге.ТзТкое ( (6001) гези1® .У1емБата ["Т$5Е1г$6\1$16"]); 

Аззеге.АгеЕсоа1 (1, сопсго11ег.Везропзе .Соок1ез.Соип®) ; 

Аззеге.АгеЕаоа1 (роо1.Тгкоебег1пд, 
сопего11ег.Везропзе .Соок1е$ ["Наз\/131ееЧВеЁоге"] .Уа1ае); 


} 


Теперь тест стал намного более читабельным. Разумеется, если тестируется пове- 
дение действия для нового посетителя, то следует также протестировать его поведение 
для возвратившегося посетителя: 


[ТезЕ] 
риЮ11с \014 Номераде Весодт1тез Ргеу1оиз_\151®ог() 
{ 
// Подготовка 
уаг сопего11ек = пем 51пр1еСопеко11ек()}; 
уаг москз = пем СопеехЕМоскК$ (сопЕко11ег); 
сопего11екг.Весиез® .СооК1ез.АаЯ (пеи НЕбрСооК1е ("Наз\/1$1Се@ВеРоге“, 
роо1.Ткиебег1па) )}; 
// Действие 
\У1еиВезо1Е гезо1Е = сопЕго11Тег.Ноперасче (); 


// Утверждение: на этот раз продемонстрировать 

// альтернативный синтаксис "ограничений" в МОп1Е 

Аззеге.Траф (гези1е.У1емМате, Т1$.Едаа1То ("НомерРаде") | Тз.Еир®у); 
Аззекг+е.Тна+ ( (роо1) гези14 .У1еирака["ТзЕ1г36\1$10"], Т1з.Ра1зе); 


Совет. Объект Сопеех(Москз можно также использовать для эмуляции дополнительных условий 
во время фазы утверждения (например, тмоскз .Ведоезе.бееор (х => х.НЕЕрМеевоа) . 
Вефокпз ("РОЗТ")). 
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Резюме 


Архитектура МУС построена на основе контроллеров. Контроллеры состоят из набо- 
ра именованных частей функциональности, которые называются действиями. Каждое 
действие реализует логику приложения. не отвечая за тонкости генерации НТМТ.-- 
разметки, позтому оно может оставаться простым, ясным и тестируемым. 

В этой главе вы узнали о том, как создавать и использовать классы контроллеров. 
Было показано, как обращаться к входным данным через объекты контекста и привязку 
параметров; как производить вывод через систему резульгатов действий; как создавать 
повторно используемое поведение, которое можно помечать атрибутами фильтров; как 
реализовать специальную фабрику контроллеров или настроить логику выбора дейст- 
вия; как писать модульные тесты для методов действий. 

В следующей главе рассматривается встроенный механизм представлений МУС 
ЕгатеутогК, а также доступные варианты трансформации объекта Моде1 или структуры 
Узеирата в готовую НТМЕ-страницу. 


ГЛАВА 1 0 
Представления 


наружи веб-приложения можно рассматривать как “черные ящики”, которые 
преобразуют запросы в ответы: на их вход поступает ОНТ, а на выходе получает- 
ся НТМЕ-разметка. Маршрутизация, контроллеры и действия являются важной частью 
внутренних механизмов АЗРМЕТ МУС, но они ничего не стоили бы, если бы не было 
возможности генерировать некоторую НТМГ-разметку. В архитектуре МУС за конструи- 
рование этого готового вывода отвечают представления. 
Вы уже видели представления в действии во многих примерах. приведенных до сих 
пор, так что приблизительно знаете, что они делают. Теперь наступило время рассмот- 
реть их еще более подробно. В этой главе вы узнаете следующее. 


® Внутренний механизм работы страниц представлений .азрх. 


® Пять основных способов добавления динамического содержимого к представле- 
нию Ме. Рогиз$. 


® Создание многократно используемых элементов управления, которые подходят 
для архитектуры МУ.С, и их применение на мастер-страницах. 


® Альтернативы механизму представлений \еБЕогилз, включая создание специаль- 
ного механизма представлений. 


Место представлений в АЗР.МЕТ МУС 


Большинство разработчиков программного обеспечения понимают, что код поль- 
зовательского интерфейса лучше держать подальше от остальной логики приложения. 
В противном случае логика представления и бизнес-логика переплетается, после чего 
отслеживать каждую из этих частей по отдельности становится невозможно. Малейшая 
модификация может легко привести к широкому распространению ошибок, и произво- 
дительность всерьез снизится. Эта постоянная проблема решается в архитектуре МУС 
за счет обособления и упрощения представлений. В веб-приложениях МУС представле- 
ния отвечают только за прием вывода контроллера и использование простой логики 
презентации для визуализации его в готовую НТМГ-разметку. 

Однако граница между логикой представления и бизнес-логикой довольно субъек- 
тивна. Скажем, если должна быть создана таблица, в которой строки через одну имеют 
серый фон, то эта задача, вероятно, будет решаться логикой презентации. Но что если 
в зтой таблице потребуется выделить определенные строки со значением суммы выше 
определенного уровня и скрыть строки, соответствующие праздничным дням? Можно 
спорить, как реализовать эту задачу — в виде бизнес-правила или в виде правила пре- 
зентации — тем не менее, выбор сделать придется. По мере обретения опыта наступает 
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понимание того, какой уровень сложности может быть приемлемым в логике представ- 
ления, и должна ли определенная часть логики быть тестируемой. 

Логика представления менее тестируема, чем логика контроллера, потому что 
представления выводят текст, а не структурированные объекты (даже ХНТМИ. разби- 
рать не просто — там есть кое-что помимо дескрипторов). По зтой причине шаблоны 
представлений обычно вообще не тестируются. Логика, подлежащая тестированию, 
обычно аккумулируется в классах контроллеров или предметной области. Некоторые 
разработчики АЗР.МЕТ МУС создают модульные тесты для вывода представлений, но 
такие тесты уязвимы даже для тривиальных изменений, подобных добавлению пробе- 
лов (иногда пробелы в НТМ!. существенны, а иногда — нет). Другие вообще не видят 
особого смысла в тестировании представлений, а предпочитают считать их не тести- 
руемыми, при этом сохраняя их предельно простыми. Если вы сторонник автоматизи- 
рованного тестирования представлений, подумайте об использовании инструмента ин- 
тегрированного тестирования, такого как пакет с открытым исходным кодом ЭЗ@епнат 
(Веер: //зе1еп1ип.ога/) или среда Аенбмею НЕ Тезё АмютаНоп Егатемогк от Миегозой 
(ВЕЕР: //милиу . содер1ех .сош/азрпет). 


На заметку! Тесты интеграции проверяют множество программных компонентов, работающих со- 
вместно, в отличие от модульных тестов, которые спроектированы для тестирования отдельного 
компонента в изоляции. Модульные тесты могут быть более ценными, потому что они естест- 
венным образом выявляют проблемы именно в точке их появления. Однако если в дополнение 
к ним имеется небольшой набор тестов интеграции, будет минимизирован риск поставки за- 
казчику версии продукта, которая потерпит крах в реальных условиях зксплуатации. Например, 
пакет 5а&епйит записывает сеанс активности в веб-браузере, позволяя определять утверждения 
о НТМЕ-злементах, которые должны появляться в разные моменты времени. Это тест интегра- 
ции, поскольку он проверяет совместную работу представлений, контроллеров, базы данных 
и конфигурации маршрутизации. Тесты интеграции не могут быть предельно точными, иначе 
единственное изменение может привести к необходимости их переписывания заново. 


Механизм представлений \МеРогт$ 


МУС ЕгатехмюогК поставляется с встроенным механизмом представлений \еБЕогте, 
который реализован в виде класса под названием МеьЕоги\1 еивпалпе. Он знаком каж- 
дому, кто работал в прошлом с АЗРМЕТ, потому что в его основу положен существукяций 
пакет \еБЕоги$, включающий серверные элементы управления, мастер-страницы и ви- 
зуальный конструктор \1за1 Звлало. Разумеется, в механизм внесен ряд усовершенст- 
вований, которые предоставляют дополнительные способы генерации НТМГ.-разметки, 
более точно соответствующей принципам АЗРМЕТ МУС по предоставлению абсолютно- 
го контроля над разметкой. 

В упомянутом механизме \еБЕогилз представления, также называемые страницами 
представлений или шаблонами представлений, являются простыми шаблонами НТМГ. 
Они работают преимущественно с одной определенной частью данных, которая предос- 
тавляется контроллером — словарем У1еирафа (который также может содержать стро- 
го типизированный объект Моде1} — и потому не могут делать чего-то большего, чем 
выводить литеральную НТМГ-разметку вперемешку с информацией, извлеченной из 
У1еирака или Моае1. Представления определенно не сообщают модели предметной об- 
ласти приложения о необходимости извлекать или манипулировать другими данными, 
как и не вызывают никаких других побочных эффектов; это простые чистые функции 
для трансформации структуры У1емрафа в НТМГ-страницу. 

Внутренне технология, поддерживаемая страницами представлений МУС. использу- 
ет серверные страницы АЗР.МЕТ У\/еЕогиз. Вот почему страницы представлений МУС 
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можно создавать с помощью тех же средств проектирования \У1за! Эва, что и приме- 
няемые в проектах \еБЕогтлз. Но в отличие от серверных страниц \/еБРогилз, страницы 
представлений АЗРМЕТ МУС обычно не имеют соответствующих файлов классов отде- 
ленного кода, поскольку они сосредоточены на логике презентации, что обычно лучше 
выражается через простой код, встроенный непосредственно в разметку АЗРХ. 


Сменяемость механизмов представлений 


Подобно любой другой части МУС ЕгатехогК. механизм представлений \еЪЕогтз 
можно использовать в неизменном виде, специальным образом настроить или полно- 
стью заменить другим механизмом представлений. Для создания собственного меха- 
низма представлений понадобится реализовать интерфейсы ту1емЕпо1те и ТУ1еи 
(пример будет приведен ближе к концу этой главы). Доступно также несколько меха- 
низмов представлений АЗРМЕТ МУС с открытым исходным кодом, которые можно вос- 
пользоваться; некоторые примеры даются в конце главы. 

Однако болынцинство приложений АЗРМЕТ МУС строятся на основе стандартного 
механизма представлений \\еБЕогплз, отчасти потому, что это механизм по умолчанию. 
отчасти потому, что он работает достаточно хорошо. Данный механизм требует подроб- 
ного рассмотрения, поэтому, за исключением нескольких мест, настоящая глава полно- 
стью посвящена механизму представлений по умолчанию. 


Основы механизма представлений Ме Рогт$ 


В предыдущих примерах вы видели, что для создания нового представления необхо- 
димо щелкнуть правой кнопкой мыши внутри метода действия и выбрать в контекст- 
ном меню пункт АДа \Мем (Добавить представление). Среда \У1зца1 За ю поместит новое 
представление туда, где должны находиться представления данного контроллера. В со- 
ответствие с соглашением, представления для РходисЕзСопЕго11ег должны распола- 
гаться в /У1емз /РходисЕ/. 

В качестве альтернативы новое представление можно создать вручную, щелкнув 
правой кнопкой мыши на папке в ЗовлНоп Ехрогег и выбрав в контекстном меню пункт 
АЧЧ=> Мем Мет (Добавить=>Новый элемент). Затем в открывшемся окне нужно выбрать 
шаблон МУС \Яе\ Рабе (или МУС \У1е\х Сощет Рабе, если хотите ассоциировать его с 
мастер-страницей). Чтобы сделать представление строго типизированным, следует 
изменить его директиву ППегИ$ с Зузеем.Иеь .Мус.У1еиРаде на Зузсен.Иер.Мус. 
У1темРаде<ТипМодели>. 


Добавление содержимого к шаблону представления 


Страница представления вполне может состоять из одной лишь фиксированной ли- 
теральной строки НТМТ, (плюс объявление <$@ Раде $%>): 


<%$@ Раде ТпБег1ез="бузеен.Мер.Мус.У1еиРаде" %> 
713 13 а <1>уегу</1> зир1е у1ем. 


Объявление <%@ Раде %> подробно рассматривается позже. Помимо него, предыду- 
щее представление содержит обычную простую НТМГ-разметку. Несложно догадаться, 
что будет отображаться в браузере. Это представление не произведет хоротно сформи- 
рованный НТМЕ-документ, так как в нем нет дескрипторов <ВЕт1> или <Ъоау>, но меха- 
низму представлений \\еБЕогпл$ зто не важно. Он готов отобразить любую строку. 
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Пять способов добавления динамического 
содержимого к шаблону представления 


Создавая представления, которые не содержат ничего, кроме статического НТМЕГ. 
вряд ли удастся достигнуть многого. Все же вы занимаетесь написанием веб-прило- 
жений, а потому необходимо предусмотреть некоторый код, который позволит сде- 
лать представления динамическими. Платформа МУС Егаше\хогК предлагает ппирокий 
спектр механизмов добавления динамического содержимого к представлениям, начи- 
ная с быстрых и простых и заканчивая развитыми и мощными. Выбор подходящего 
способа возлатается на вас как разработчика. 

В табл. 10.1 представлен обзор доступных способов добавления динамического вы- 
вода в представления. 


Таблица 10.1. Способы добавления динамического вывода в представления 


Е РС... В 
Способ Когда используется 


Встроенный код Для небольших, самодостаточных частей кода представления, таких как 
операторы 1 и Еогеась, и для вывода строк в поток ответов с примене- 
нием синтаксиса <$= уа]ле %>. Встроенный код — зто основной инстру- 
мент, и большинство других приемов построено на его основе. 


Вспомогательные Для генерации одиночных НТМЕ-дескрипторов или небольших коллекций 

методы НТМЕ НТМЕ-дескрипторов на основе данных, извлекаемых из У1еаха или 
Моде1. Любой метод .МЕТ, который возвращает строку, может быть вспомо- 
гательным методом НТМЕ. АЗРМЕТ МУС поставляется с широким диапазо- 
ном базовых вспомогательных методов НТМЕ. 


Серверные элементы Для применения встроенных в АЗРМЕТ элементов управления \Ме Рог 

управления или для совместного использования совместимых злементов управления из 
проектов МебРоггиз. 

Частичные Для совместного использования сегментов разметки в нескольких пред- 

представления ставлениях. Это легковесные многократно используемые элементы управ- 


ления, которые могут содержать логику представления (т.е. встроенный 
код, вспомогательные методы НТМЁ и ссылки на другие частичные пред- 
ставления), но никакой бизнес-логики. Они подобны вспомогательным 
методам НТМЬЕ, за исключением того, что создаются с помощью шаблонов 
АЗРХ, а не в коде С#. 


Графические элементы Для создания многократно используемых элементов управления пользова- 

НЕи1 .ВепаегАсЕ1от()  тельского интерфейса или графических элементов, которые могут включать 
логику приложения наряду с логикой презентации. Каждый раз при визуа- 
лизации такого графического элемента это требует запуска отдельного 
процесса МУС, с методом действия, который выбирает и визуализирует 
собственный шаблон представления для включения в поток ответа. 


Все перечисленные в табл. 10.1 способы по очереди рассматриваются далее в главс. 
Дополнительные сведения о повторном использовании серверных злементов управле- 
ния У\еЕогиа$ в приложениях МУС можно найти в главе 16. 


Применение встроенного кода 


Первый и простейший способ визуализации динамического вывода из страницы 
представления связан с применением встроенного кода, те. блоков кода, представлен- 
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ных в синтаксисе угловых скобок (<%...$%>). Подобно аналогичному синтаксису в РНР, 
Вайз, УЗР. классическом АЗР и многих других платформах разработки веб-приложений, 
это синтаксис для вычисления результатов и встраивания простой логики в файл, ко- 
торый в остальном выглядит подобно обычной НТМЕ-разметке. 


Предположим, например, что есть страницу представления по имени ЗпоиРегзоп.азрх. 
которая предназначена для визуализации объектов некоторого типа Регзоп, определен- 
ного следующим образом: 


руЮю11с с1азз Регзоп 
{ 

риБ11с 10Е Регзоптр { дее; зе; } 

рУБ11с зег1па Маме { деф; зеф; } 

рою11с 1пЕ Аде { дее; зе; } 

руб11с ТСо11есЕ1оп<Регзой> СЬ119кеп { деё; зек; } 
} 


Для удобства страницу 5ВочРегзоп.азрх можно превратить в строго типизирован- 
ное представление (о них будет рассказываться далее в этой главе), установив в списке 


\Леми даа с!а3$ (Класс данных представления) значение Регзоп при первоначальном 
создании представления. 


После этого $5ВомРегзоп.азрх может визуализировать свое свойство Моде1 типа 
Регзоп, используя для этого встроенный код: 


<%@ Раде Гапдиаде="С4" 
Тпрег15="бузтеп.Меб.Мус.\У1еиРаде<\У1енТезе5 .Моде1з.Регзоп>"%> 
<!РОСТУРЕ Бет1 РОВЬТС "-//МЗС//ОТЬ ХНТМЬ 1.0 Ткапз1Е1опа1//ЕМ" 
"ВЕЕР: //ми. м3 . оса/ТВ/хВет1/РТО/ х6и11-Егап$1(1опа1.9Е4"> 
<ВЕт1 хи1пз="ВЕЕр://ми. м3 -ог9/1999/хНЕм1" > 
<реаа> 
<Е1Е1е><$= Мо@е1.Маме %></61(1е> 
</реад> 
<Боау> 
<Н1>ТпЕогта фот аросе <$= Моде1.Мате %></р1> 
<а1у> 
<%= Мо4е1.Маще %> 15 
<%= Моде1.Аде %> уеагз о19. 
</91у> 
<р3>СЬ119геп:</63> 
<и1> 
<% ЕогеасВ (хак св11А зп Моде1.СЬаТАгеп) { %> 
<11> 
<Ь><%= ср11а.Маме $></Ъ>, аде <%= сЬа1а.Аде %> 
</11> 
<$ } %> 
</01> 
</Боду> 
</вЕт1> 


Экран, визуализированный для некоторого объекта Регзоп, показан на рис. 10.1. 

Если вы имели дело с АЗР.МЕТ \МеЪЕогтз в течение последних нескольких лет, то 
встроенный код в этом примере (а, возможно, и весь ранее приводимый встроенный 
код) может вызвать крайний дискомфорт. Тем не менее, для беспокойства нет причин: 


со временем мы разберем все сложные вопросы, и вы обретете доселе не виданное за- 
мечательное чувство свободы. 
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| шРогтаНоп аБоп+ Ропа14 
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Рис. 10.1. Вывод примера шаблона представления 


Причины пригодности встроенного кода 
для шаблонов представлений МУС 


Применение встроенного кода в АЗРМЕТ \МеБЕогтз обычно не приветствуется, по- 
скольку предполагается, что страницы \еБЕогтз должны представлять иерархию сер- 
верных элементов управления, а не страницу НТМГ.. Платформа \/еБЕогиаз ориентирова- 
на на создание иллюзии разработки графических пользовательских интерфейсов в стиле 
УЛпао\з Еогтиз, а в случае использования встроенного кода эта иллюзия разрушается. 

Совсем иначе обстоят дела в МУС Егате\хогК. Здесь разработка веб-приложения 
трактуется, как она есть, без попыток создать впечатление построения настольного при- 
ложения, и потому нет необходимости в имитации чего-то другого. НТМТ.-разметка — 
это текст, а генерировать текстовые шаблоны совсем не сложно. Многие платформы 
веб-программирования с годами приходили и уходили, но идея построения птаблонов 
НТМЕ постоянно возвращалась в той или иной форме. Это естественным образом под- 
ходит для НТМГ. и хорошо работает. 

Может возникнуть вопрос насчет разделения понятий. Разве не нужно отделять ло- 
гику от презентации? Безусловно, нужно! Как АЗРМЕТ \еБЕогтиз, так и АЗРМЕТ МУС 
стараются помочь разработчику отделить логику приложения от ответственности пре- 
зентации. Разница между двумя платформами состоит лишь в том, где в них проходит 
линия границы. 

АЗР.МЕТ \’еБЕоттоз отделяет декларативную разметку от процедурной логики. 
Файлы интерфейсного кода АЗРХ содержат декларативную разметку, управляемую про- 
цедурной логикой в классах отделенного кода. И такой подход хорош, поскольку позво- 
ляет в определенной степени разделить ответственность. Недостаток состоит в том, что 
на практике примерно половина класса отделенного кода занимается тонкими мани- 
пуляциями элементами управления пользовательского интерфейса, а другая половина 
имеет дело и манипулирует моделью предметной области приложения. Таким образом. 
понятия презентации и логики приложения смешаны в этих классах отделенного кода. 

Платформа МУС ЕгатехогК появилась благодаря тому, что были извлечены уроки 
из традиционных \@БЕогтиз, а также в ответ на то, что конкурирующие платформы веб- 
приложений продемонстрировали свои преимущества в реальном применении. Пришло 
понимание того, что презентация всегда включает некоторую логику, поэтому наиболее 
удобно отделять логику приложения от логики презентации. Контроллеры и классы мо- 
дели предметной области заключают в себе прикладную логику и логику предметной 
области, в то время как представления содержат презентационную логику. До тех пор. 
пока логика представления остается простой, намного яснее и естественнее помещать 
ее непосредственно в файл АЗРХ. 
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Разработчики, использующие другие платформы веб-разработки, основанные на 
МУС, сделали вывод, что это наиболее эффективный способ структурирования прило- 
жений. Нет ничего крамольного в использовании нескольких конструкций 1ЕЁ и Еогеась 
в представлении — в конце концов, логика презентации должна хоть что-нибудь делать. 
Однако сохраняйте ее простой, и вы получите очень аккуратное приложение. 


Действительная работа представлений МУС 


Итак, теперь вы знакомы с концепцией встраивания кода. Но прежде чем перехо- 
дить к рассмотрению других приемов добавления динамического содержимого, необхо- 
димо выяснить, как все это в действительности работает. Для начала мы рассмотрим 
основные механизмы птаблонов \МебЕогтз АЗРХ, их компиляцию и выполняются, а за- 
тем подробно разберем работу У1емрака и Моде1. 


Компиляция шаблонов АЗРХ 


Каждый раз, когда создается новая страница представления, среда У1зиа! Зба@юо пре- 
доставляет шаблон АЗРХ (например, Му\/1еи.азрх или МуРагЕ1а1\У1еи.азсх). Несмотря 
на то что зто шаблон НТМГ, он может также содержать встроенный код и серверные 
злементы управления. При развертывании приложения \еБЕогилз или МУС на сервер 
обычно помещается множество нескомпилированных файлов АЗРХ и АЗСХ. Когда ме- 
ханизм АЗРМЕТ обращается к этим файлам во время выполнения, он использует специ- 
альный встроенный компилятор страниц для трансформации файла в класс .МЕТ. 

Файлы АЗРХ всегда начинаются с директивы <%@ Раде %>. Эта директива указывает 
как минимум базовый класс „МЕТ; от которого должен наследоваться шаблон АЗРХ, и поч- 
ти всегда указывает язык „МЕТ, на котором написаны блоки встроенного кода. Например: 


<%@ Раде Тапдиаде="С#" ТпБег1е5="бузфет. Иер .Мус.\У1еиРаде" %> 


Очень полезно анализировать код, генерируемый компилятором \еБЕогилз из фай- 
лов АЗРХ. Его можно обнаружить во временных скомпилированных библиотеках ОШ. в 
папке с: \Озег5\вашеРегистрационноеИмя\ Аррраса\Госа1\Тепр\Тетрокаку АЗР.МЕТ 
Е11ез\ (это местоположение по умолчанию в среде УЯпдо\’$ \1зёа; обратите внимание, 
что папка Арррафа по умолчанию скрыта). Затем эти библиотеки можно пропустить че- 
рез какой-нибудь декомпилятор .МЕТ; вроде популярного инструмента Кеа Са „МЕТ 
ВеНестог (доступного для свободной загрузки по адресу ини. гед-дафе .сош/ргодиасез/ 
теЁ1есеок/). Например, приведенная ниже страница представления: 


<%@ Раде Тапдиаче="С#" Трвег1Ез="бузфет. Мер .Мус.У1еиРаде<Ак(1с1ерафа>" %> 
<ВЕи1 хи из="ВЕЕр: //ми. м3 .ог9/1999/хНЕш1" > 
<реаа> 
<511е>Не11о</%1%1е> 
</веаа> 
<Боау> 
<61><%= Моде1 .АгЕ1с1еТ1е1е %></61> 
<$= Моде1.АкЕ1с1еВоду %> 
<р2>5ее а1зо:</12> 


<и1> 
<$ ЕогеасВ (3 г1па иг1 1ш Моде1.Ве1афеа0т1$} { $%> 
<11><%= ик1 %></11> 
<$ } %> 
</о1> 
<азр:Тпаде гопае="зегкуег" Тр="ТиадебекуехСойЕко1" /> 
</Боау> 


</ВЕи1> 
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компилируется в следующий код: 


рчЮ11с сфа$$ у1еиз Воше му1п11тесодераде азрх : У1емРаде<АкЕ1с1ерафа> 
{ 


ргосес®еа Тиаде ТпадебегуекСопего1; 


ргофестеа оуегг1ае уо1а ЕгамемокгКкТи1Е1а112те (} 
{ 

_ Ву11аСопеко1Ткее (); 
} 


рг4уаСе уо1а _ Ви11аСопско1Ткее () 

{ 
ТпадебекуегСопеко1 = пеи Ттаде() { 10 = "ТмадебекуехгСопеко!" }; 
зеЕВепаегтМеероаре1едате (пеи ВепаегМе(поа (&115._ Вепдег)); 

} 


реууафе у014 _ Вепдех (Неиш1ТехеИк1Еек опЕрие, СогпЕго1 сЬ11АкепСопфалтек) 


{ 
оиерие .Иктее ("\х\п<рем хииз=\"НЕЕр://мии. м3 .ога/1999/хнетл\" >\к\р 


<пеаа>\к\п <Е1Е1е>Не11о</+141е>\к\п </Веад>\г\п <роду>\к\г 
<р1>"); 

опЕрае.Иг1се (Моде1.АкЕ1с1еТ1(1е); 

оиЕрие.Игтее ("</р1>\к\п ®):; 

оперуие.Иглке (Моде1.АкЕ1с1еВоду) ; 

опЕрие.Иг1 ее ("\х\п <р2>5ее а1зо:</в2>\к\п <и1>\к\п #): 


ГогеасВ (5©+1п9 иг 1п Моае1.Ве1асед0т1$) 
{ 


оиЕрие.Иг1 те ("\к\п <11>"); 
очЕрие.Ик1 ее (пгк1); 
оиЕрие.Иг1 те ("</11>\г\п п) 

} 

оиЕрие.Игаее ("\х\п </и1>\к\п Е 


ср11агепСопеа1тег.Сопего1$ [0] .ВепдехСопего1 (оиЕриЕ); 
очЕриг.Ик1те ("\г\п </Юоду>\г\п</БЕт1>\к\ п"); 


} 


Несмотря на то что декомпилированный код несколько упрощен, он достаточно точ- 
но отражает суть. Ключевой момент, который здесь следует отметить, состоит в том. 
что каждый фрагмент литерального НТМГ, — переводы строк и все прочее — превра- 
щается в вызов НЕп1ТехЕИк1Сег.Их1{е (), и встроенный код просто передает его мето- 
ду _ Вепаег() без изменений, поэтому он становится частью процесса визуализации 
В данном примере серверные элементы управления, подобные ТпадебехуекСопе:с- 
разбираются и становятся переменными-членами скомпилированного типа, а вызо: 
их метода Веп@егСопего1 () помещается в соответствующее место. 

Обычно специально затлядывать в скомпилированное представление файла АЗРХ не 
обязательно. Однако это полезно для понимания, как на самом деле встроенный код в 
серверные элементы управления вызываются во время выполнения. 

Файл АЗРХ/АЗСХ можно редактировать в любое время, потому что встроенный ком- 
пилятор заметит, что это было сделано, и автоматически перекомпилирует обновлен- 
ную версию при следующем выполнении. В резульгате получается сочетание гибкости 


интерпретируемого языка и преимуществ компилируемого языка, относящихся к вре- 
мени выполнения. 
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На заметку! Для компиляции решения в \Мзиа! Эдо необходимо выбрать пункт меню Вийа=>Вийа 
Зоиоп (Построение=> Построить решение) (либо нажать <ЕБ> или <Си+$НИН-В>). В случае 
наличия ошибок в коде компилятор выдаст соответствующие сообщения. Однако этот процесс 
компиляции не затрагивает файлы А$РХ и А$СХ, потому что они компилируются на лету во вре- 
мя выполнения. Если представления должны быть включены в обычный процесс компиляции 
(например, чтобы получить раннее предупреждение о возможных ошибках компиляции време- 
ни выполнения), можно воспользоваться параметром настройки проекта <МусВи119\1емз>. 
Более подробно это объясняется в главе 14. 


Модель отделенного кода 


Если вы имели дело с АЗРМЕТ УеБЕогтз, то определенно видели классы отделен- 
ного кода. Идея состоит в том, что вместо наследования страниц непосредственно 
от зузеет.Мер.ОТ.Раде (стандартного базового класса для традиционных страниц 
М\еБЕогил$) можно построить промежуточный базовый класс (который сам унаследо- 
ван от ЗузЕет.Иер.0Т.Радче) и помещать в него дополнительный код, который влияег 
на поведение страницы. Модель отделенного кода была разработана для платформы 
АЗРМЕТ \еБЕогоз$ и лежит в основе функционирования страниц \еБЕогтиз: класс отде- 
ленного кода служит для размещения в нем обработчиков событий каждого из объектов 
серверных элементов управления. определенных в шаблоне АЗРХ. 

Формально в МУС также можно создать страницу представления с классом отделен- 
ного кода. Для этого в среде \У15ца1 Зи понадобится поместить шаблон \МеЬ Еогт в 
нужное место представления и затем изменить его класс отделенного кода, унаследовав 
его от бузсем. мер .Мус .У1емРаде или бузЕем.Иер.Мус .У1еиРаде<ТипМодели>. 

Однако классы отделенного кода почти всегда излишни и нежелательны в АЗРМЕТ 
МУС, так как но причине разделения обязанностей в МУС представления должны оста- 
ваться очень простыми, и потому они редко нуждаются в обработчиках событий отде- 
ленного кода. Классы отделенного кода пригодны в качестве последнего средства, когда 
требуется повторно использовать старый серверный элемент управления \/еЬЕогпа$, для 
которого нужно выполнить некоторую инициализацию в обработчике Раде _Гоа@(). 
Добавление слишком большого числа обработчиков отделенного кода для внедрения ло- 
гики в разные точки жизненного цикла страницы приводит к утере всех преимуществ 
АЗРМЕТ МУС. Если же по той или иной причине это необходимо, следует рассмотреть 
возможность построения приложения \еБЕогтз или определить некоторый гибрид 
У\!’еЕогт$ и МУС, как будет описано в главе 16. 


Структура Уземрата 


Как известно, в АЗРМЕТ` МУС контроллеры поставляют данные в представления, пе- 
редавая объект под названием \У1емРафа типа У1емРафа11 с+1опаху. Этот тип предла- 
гает два способа передачи данных. 


1. С использованием семантики словаря. Каждый экземпляр У1емРафа01сЕ1опагу — 
это словарь, который можно заполнять произвольными нарами “имя/значение” 
(запример, устанавливая \У1емПата["дафе"] = Раъет1ие. Мом). Имя каждой пары 
имеет тип 5 х1п<а, а значение — тип об] есь. 


2. С использованием специального свойства Моае1. Каждый экземпляр 
У1емРакар1сЕ1опагу также имеет специальное свойство под названием Моде], 
которое хранит произвольный обес. 
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Например, можно записать так: У1емРа®а.Моае] = пуРегзоп'. В шаблоне пред- 
ставления для ссылки на это свойство можно использовать сокращение, записы- 
вая просто Моае1 вместо У1емрафа .Моде\. 


Ценность первого способа очевидна — можно передавать произвольную коллекцию 
данных. Ценность второго снособа зависит от того, от какого типа унаследована стра- 
ница представления. АЗРМЕТ МУС предлагает два варианта выбора базового класса для 
страницы представления. 


» Если представление унаследовано от У1еиРаде, значит, создано слабо типизиро- 
ванное представление. В классе У1емРаде определено свойство Узлемрафа типа 
\1емРафа01сЕ1опаху. В этом случае У1емПа®а .Моде1 имеет неснецифичный тип 
ор] есе, который не слишком полезен. Слабо типизированная страница представ- 
ления больше подходит в ситуации, когда планируется использование У1емПафа 
исключительно как словаря, с полным игнорированием Моае1. 


® Если представление унаследовано от У1емРаде<Т>. где Т — некоторый снециаль- 
ный класс модели, значит, создано строго типизированное представление. В клас- 
се У1емРаде<Т> определено свойство У1емРафа типа У1емПРафар1сЕ1опаку<Т>. 
В этом случае У1емрафа.Мо4е1 имеет тип Т, так что можно легко извлекать 
данные из него с помощью средства п\еШЗепзе. Именно эту возможность будет 
предоставлять среда У15на1 Зло после отметки флажка Сгезме а топа фуред 
ме\ (Создать строго типизированное представление) в диалоговом окне Аба \Ле\м 
(Добавить представление). 


Контроллерам ничего не известно об отличиях между этими двумя вариантами. 
Независимо от вашего выбора, они всегда применяют У1еиРафар1сЕ1опагу. Однако 
строго типизированные представления помещают входящий У1емРафа01сЕ1орагу 
в оболочку У1емрафа01сЕ1опаху<Т>, обеспечивая строго типизированный доступ к 
\У1емБафа.Моае1 при написании таблона АЗРХ. Конечно, это зависит от возможности 
приведения любого входящего объекта У1емРафа .Моае1 к типу Т; если такая возмож- 
ность отсутствует, возникает исключение времени выполнения. 

На практике, если страница представления в основном ориентирована на визуали- 
зацию некоторого объекта модели предметной области, применяется У1емРаде<Т>, где 
Т — тип объекта этой модели предметной области. Когда выполняется визуализация 
коллекции объектов Регзоп, можно использовать У1еиРаде<ТЕпипегар1е<Регзоп>>- 
Это обеснечит максимальное удобство. В то же самое время можно добавлять произ- 
вольные элементы словаря, если нужно пересылать также и другие данные, вроде со- 
общений о состоянии. 


Визуализация элементов У1еирафа 
с использованием \1емра{фа .Е\уа1 


Одним из основных применений встроенного кода является извлечение и ото- 
бражение данных из структуры У1емрафа, трактуя ее либо как словарь (например. 
<%= У1еирафа["неззаае"] %>), либо как строго типизированный объект (например. 
<%$= Моае1.таз Ордаферафе.Уеахк %>). Для доступа к значениям, хранящимся в лю- 
бом месте У1еиРафа или Моде1, служит ранее не упоминавитийся метод Еуа1 () класса 
У1емрафар1с®1ораку. который рассматривается ниже. 


*Это происходит неявно, когда метод действия вызывает представление, возвращая 
У1ем (пуРегзоп). Разумеется, метод действия может также добавлять некоторые нары “имя 
значение” в У1емПата. 
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Метод Еуа1 () производит поиск по всему графу объектов У1емРаса — и в словаре, и 
в элементах объекта Моде] — с использованием синтаксиса разделенных точками лек- 
сем. Предположим для примера, что визуализируется <%= \У1емБака.Еуа1 ("Ч4ефа113. 
1аз1091п.уеак") %>. Каждая лексема в разделенном точками выражении восприни- 
мается либо как имя элемента словаря, либо как имя свойства (без учета регистра сим- 
волов). Еуа1 () проходит рекурсивно и по словарю, и по объекту Моде1 в определенном 
порядке, в поисках первого отличного от па11 значения. В рассматриваемом примере 
могут быть обнаружены следующие элементы: 


® \У1емрата["4ефа1]3.1азЕ1о91п.уеак"] 
® \У1емрата["Чера1]3"] .1аз 1од1и.уеак 
® \У1емПафа["Чера1]1$.1азЕ1од1т"] .уеак 
® \У1еирага["Чефа113"] ["1аз1о94п"] ["уеах"] 


® \У1еирРафа.Моде1 .ПРефа11$.ГазЕГод1и.уеаг 


® \У1емПаба.Мо4е1 .Пефа11$["1азЕ1од1п .уеак"] 


Это лишь некоторые из многих возможных путей разрещения приведенного выраже- 
ния. Метод Еуа1 () на самом деле проверяет все возможные комбинации имен элементов 
словаря и имен свойств, сначала в У1еиПафа как в словаре, а затем в У1еиРафа.Моае1, 
останавливая поиск при нахождении значения, отличного от пи11. 


Алгоритм поиска, реализованный в УтеиПака. Еуа1 


Детали реализации алгоритма поиска Еха1 (} несколько темны и загадочны и обыч- 
но при повседневном использовании не имеют особого значения. Если кратко, то это ре- 
курсивный алгоритм, который начинается с интерпретации выражения как одиночного 
ключа словаря, с последующим удалением по одной лексеме за раз, пока не останется 
ни одной. Таким образом, на верхнем уровне рекурсии он ищет следующие элементы: 


1. Уземрака ["Ч9ефа113.1аз®1о91п.уеак"] 
2. УтеиПака ["Чефа113.1аз®1од1а"] 
3. У1емРафа["Чефа115"] 


Если любой из этих элементов вернет значение, отличное от по11. алгоритм вызыва- 
ет себя рекурсивно, чтобы оценить остальную часть выражения на только что найден- 
ном объекте. После каждой попытки использования лексемы в качестве ключа словаря, 
эта же лексема будет пробоваться как имя свойства (без учета регистра символов} ска- 
нируемого объекта. На верхнем уровне рекурсии будет также предприниматься попыт- 
ка использовать каждую лексему как имя свойства в У1емПаба.Моде1, и если при этом 
обнаруживается значение. алгоритм вызовет себя рекурсивно для вычисления остав- 
шейся части выражения на этом объекте. 

Детально разбираться в порядке функционирования этого алгоритма вовсе не обя- 
зательно, поскольку на практике весьма маловероятно, что будут обнаружены два 
разных значения при разных интерпретациях одного и того же выражения (напри- 
мер, вряд ли будут одновременно существовать элементы У1емРафа["а"] ["ю.с"] и 
У1емРафа["а.ъ"] ["с"]). Важно понять, что алгоритм проверяет все возможные интер- 
претации выражения, отдавая приоритет элементам словаря в У1еирата перед свойст- 
вами У1емРафа.Моде1. 

Если вы озабочены производительностью этого алгоритма, то имейте в виду, что 
обычно выражение содержит относительно немного лексем, разделенных точками, по- 
этому будет всего несколько возможных интерпретаций, а поиск в словаре обходится 
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очень дешево. Вдобавок метод Еуа1 (} должен выполнять некоторую рефлексию для об- 
наружения свойств, имена которых соответствуют лексемам в выражении, но затраты 
на это незначительны по сравнению со стоимостью обработки всего запроса. На прак- 
тике почти наверняка не возникнет никаких проблем. 


На заметку! Метод Еуа1 (} ищет только элементы словаря и свойства. Он не может вызы- 
вать методы (так что не пытайтесь применять что-то вроде УлемПафа.Елха1 ("зотелфем. 
сеебомеЕр1пч ()") } и не умеет извлекать значения из массивов по числовому индексу (по- 
этому не получится использовать и код наподобие У1емПара.Елуа1 ("“тупопфегз [5]")). 


Использование УтеиПата.Еуа1 для 
упрощения встроенных выражений 


С помощью метода Ета] (} некоторые встроенные выражения можно записать в б0- 
лее читабельном виде. Например, следующее выражение: 


<%= У1еираба["Мате"] ?? Моде1.Маше %> 
можно упростить до такого вида: 
<$= Утеирафа.Еуа1 ("Мате") %> 


Если хотите, чтобы У1емРафа.Еха1 (} форматировал свой вывод в каком-то опре- 
деленном порядке, можете передать второй параметр типа з&х1п9 но имени Еогтае. 
Это поместит У1еиРафа.Еуа] () в оболочку зЕглпа.Еогма® (), так что результат будет 
встроен на место любой лексемы {0} нараметра Еогта®. Например, с помощью этого 
прием, код 


<$ 1Е (У1темрата .Сопфа1тзКеу ("аефа113")) { %> 
Таз 1оддеа 11: 
<$%= ((0зегОефа113) У1емрата["@еса115$"]) .ТазеТод1п.Тобек1поа ("МММ 949, уууу") %> 


можно упростить до следующего: 
<%= У1емрафа.Е\уа1 ("Чефа11з.ГазЕТГодли", "Таз 1оддеЯ 1п: {0:МММ аа, уууу}") $%> 


Очень скоро будет показано, как встроенные в МУС ЕгатаемюгК вспомогательные ме- 
тоды НТМЕ вызывают У1еиПафа.Еха1 (} для автоматического заполнения элементов 
управления, упрощая их использование в распространенных сценариях. 


Использование вспомогательных методов НТМЁЕ 


Несмотря на то что представления МУС обеспечивают очень тонкий и низкоуровне- 
вый контроль над НТМГ-разметкой, было бы утомительно вновь и вновь вводить новто- 
ряющиеся фрагменты этой разметки. Вот почему МУС ЕгаглемогК предлагает птирокий 
диапазон вспомогательных методов НТМЕ. которые визуализируют часто используе- 
мые фрагменты разметки с помошью более короткого и аккуратного синтаксиса, под- 
держиваемого средством ПицеШ$епзе. 

Например, вместо набора кода 


<1проЕ паме="соштепе" 19="сопиепе" суре="техс" 
уа]1ие="<$%= НЕи1.Епсоае (У1ем Баба .Еуа1 ("сотмепе")) %>" {> 


можно ввести его сокращенный эквивалент: 


<%$= НЕт1 .ТехЕВох ("сошмере") %> 
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Эти методы называются вспомогательными нотому, что они действительно оказывают 
помощь. Это не элементы управления в том смысле, в каком это понимается в \©БЕогилз; 
они представляют собой просто сокращенный способ генерации НТМГ-дескрипторов. 

Представления и частичные представления имеют свойство но имени НЕм1 
(типа бузЕем. Мер .Мус .нЕм1Не?рег для слабо типизированных и бузкем.Иер.Мус. 
Ни] Нне]1рехг<Т> для строго тинизированных представлений), которое является на- 
чальной точкой для доступа к этим вспомогательным методам. Несколько всномога- 
тельных методов НТМ!, естественным образом реализованы в классе НЕм1Не]1рехк, но 
болыпинство из них — это на самом деле расптиряющие методы, которые находятся 
в бузеет.Мер.Мус.НЕт1 и расширяют НЕи1Не1рег. Файл мер. сопЕ19 в АЗРМЕТ МУС 
по умолчанию импортирует пространство имен через узел <папезрасе>, ноэтому для 
доступа к вспомогательным методам в шаблоне представления не нотребуется делать 
ничего снециального. Просто наберите <%= НЕп1. и увидите все доступные опции. 


Совет. Разработчики платформы АЗР МЕТ МУ\УС решили реализовать все вспомогательные методы 
НТМЕ в виде расширяющих методов в отдельном пространстве имен, так что при желании их 
можно заменить альтернативным набором. Создав собственную библиотеку расширяющих ме- 
тодов НЕп1Не1Трег, возможно, с АР!-интерфейсом, совпадающим с встроенным, можно будет 
исключить 5узтем. Иер .Мус. НЕТ из мер . сопЁза и импортировать взамен собственное 
пространство имен. Шаблоны представлений изменять не придется; они просто переключатся 
на использование специальных вспомогательных методов. 


Встроенные вспомогательные методы МУ\УС РагтемогКк 


Давайте преднримем краткий экскурс но всем встроенным вспомогательным мето- 
дам НТМГ.. Следует отметить. что болыпинство из них имеют но нескольку перегрузок, 
соответствующих визуализации различных атрибутов НТМГ-дескринторов; некоторые 
методы насчитывают свыше десяти перегрузок. Возможных комбинаций настолько 
много, что перечислить их все трудно. Вместо этого для каждой группы вспомогатель- 
ных методов НТМГ, будут приведены характерные примеры, а также описание их основ- 
ных вариаций. 


Визуализация элементов управления вводом 


Первый набор вспомогательных методов генерирует НТМГ-код знакомого набора эле- 
ментов управления вводом, включающего текстовые поля, флажки и ти. (см. табл. 10.2). 


Таблица 10.2. Вспомогательные методы НТМЕ для визуализации элементов 
управления вводом 


Описание Пример 


Флажок Вызов: Нет . СпескВох ("туСвескЬох", Га15е) 
Вывод: <1прие 1а="туСнескрох" пате="туСвескБох“" 
фуре="свескрох" уа1ие=“екие" /> 
<1приЕ паме="муСВескрох" суре="Р1а4еп" уа1ае="Еа1 зе" /> 


Скрытое поле Вызов: НЕ]. .Н19деп ("шуН1ааепт", "уа1") 
Вывод: <1прие 19="туН1Адеп" папе="туН1д9еп" 
фуре="В1Ааеп" уа1ще=“уа1" /> 
Переключатель Вызов: НЕ]. .Вад1оВие коп ("тувад1ороееоп", "уа1", Е гие) 


Вывод: <1приыф свескед="свескея" 19="“тувад1оБи сов" 
пате="туВаО1ороЕсоп" фуре="га@а1о" уа1пе="уа1" /> 
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Окончание табл. 10.2 


Описание Пример 


Поле ввода пароля Вызов: Нет] .Раззмога ("туРаззиог4", "ха1") 

Вывод; <1прие 19="туРаззиога" паше=“туРаззиока" 
туре="раззиог@" ха1иае="уа1" /> 
Текстовая область Вызов: НЕ .ТехЕАтеа ("туТехеагеа", "уа1", 5, 20, по11) 


Вывод; <ЕехЕатеа со15="20" 19="туТехеагеа" 
паме="тмуТехфатеа" гоиз="5">уа1</фехфагеа> 


Текстовое поле Вызов: НЕш1 .ТехЕВох ("туТехЕФох", "уа1") 


Вывод: <1приЕ 149="туТехЕФох" пате="туТехерох" 
р У 
туре="фехе" уа1пе="уа1" /> 


На заметку! Обратите внимание, что вспомогательный метод генерации кода флажка (нЕт1. 
СфескВох () } визуализирует два элемента управления. Первым является сам флажок, как и 
следовало ожидать, а вторым — скрытый элемент управления вводом с тем же именем. Это 
решает проблему, состоящую в том, что для неотмеченного флажка браузер не отправляет зна- 
чение. Наличие скрытого элемента управления вводом означает, что, когда флажок неотмечен, 
МУС ЕгатемюгК получит значение скрытого поля (Еа1 зе). 


Получения значений элементами управления вводом 


Каждый из этих элементов управления пытается заполнить себя, выполняя ноиск 
значений в следующих местах, перечисленных в порядке их приоритетов. 


1. У1емрафа.Моде] 5$ афе ["сопЕго1Маме"] .Уа1ае.Вам\атае. 


2. Параметр уа1ие. переданный вспомогательному методу НТМГ. Если вызвана его 
перегрузка без параметра уа1ае, то УлеиПаба.Еха1 ("имяЭлемента"). 


Мое15сафе — это временное хранилище, используемое АЗРМЕТ МУС для хранения 
значений, которые пользователь пытался вводить, а также оштибок привязки и провер- 
ки достоверности. Об этом подробно рассказывается в главе 11. Пока просто знайте, что 
Мое] 5Еате находится в начале списка, потому его значения переопределят любые зна- 
чения, установленные явно. Это означает, что вспомогательному методу можно пере- 
дать любое явное значение в параметре уа1ое, которое станет значением по умолчанию 
или исходным, но когда представление повторно визуализируется носле неудавшейся 
проверки достоверности, вспомогательный метод сохранит любое значение, введенное 
пользователем, отдавая ему предпочтение перед значением по умолчанию?. Описанный 
механизм более подробно рассматривается в следующей главе. 

Все вспомогательные методы НТМГ, предлагают перегрузку, которая не требует пере- 
дачи нараметра уа1е. При вызове такой перегрузки элемент управления вводом попы- 
тается получить значение из У1емРафа. Например, приведенный ниже вызов 


<%$= НЕТ .ТехЕВох ("ОзехМаме") %> 
эквивалентен следующему вызову: 


<%= НЕ .ТехЕВох ("ОзехМаме", У1емрата.Еха1 ("ОзехМаще")) %> 


? Если быть точным, то метод НЕп1 .Раззиота() ведет себя иначе, чем другие всномогатель- 
ные методы: в соответствие с проектным решением он не восстанавливает никакого пре- 
дыдущего значения из Моае15тафе. Это сделано для ноддержки типичных экранов входа. 
где после сбоя регистрации поле пароля должно быть сброшено, чтобы пользователь мог 
попытаться заново ввести правильный пароль. 
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Это означает, что вспомогательный метод извлечет начальное значение из 
У1емрака ["ОзехМапе" ], а в случае отсутствия там отличного от пи11 значения он нпо- 
пытается обратиться к У1емРафа .Моде1 .ОзехМапе. 


Добавление к дескриптору произвольных атрибутов 


Все вспомогательные методы НТМГ. перечисленные в табл. 10.2. позволяют визуа- 
лизировать произвольную коллекцию донолнительных атрибутов дескрипторов, переда- 
ваемых в нараметре но имени вп] АБЕх1афез, например: 


<$= Нейт. ТехЕВох ("шубехе", “уа1", пем { зомеАЕЕх1Раее = "зотеуа1" }) %> 
Результирующий НТМГ-дескритор выглядит следующим образом: 


<1приЕ 1а="тубехе" папе="тубехе" зотеАЕк1риЕе=" зотеуа1" 
суре="техе" уаТае="уа1" /> 


Как показано в этом примере, ВЕ и1 АЕЕх1Бофез может быть анонимно типизирован- 
ным объектом (или любым произвольным объектом) — он рассматривается как коллек- 
ция элементов “тин/значение” с использованием рефлексии для выбора имен свойств 
и их значений. 


Совет. Компилятор С# не разрешает использовать в качестве имен свойств зарезервированные 
слова С#. Поэтому если вы попытаетесь визуализировать произвольный атрибут с1азз, пе- 
редав пем { с1азз = "муСззС1азз" }, то получите ошибку компиляции (с1аз$ — это 
зарезервированное слово С#). Во избежание этой проблемы, предварите любое зарезерви- 
рованное слово С# символом @ (например, { @с1азз = "тусззС1азз" }). Это сообщит 
компилятору о том, что его не следует интерпретировать как ключевое слово. Символ @ от- 
брасывается во время компиляции (поскольку это лишь подсказка для компилятора), поэтому 
атрибут будет выглядеть просто как с1азз. 


При желании можно передать объект ВБЕи1АЕг1иеез, реализующий Тр1сЕ1опагу< 
зЕх1та, ою]ес®>, который избавит платформу от необходимости использовать рефлек- 
сию. Однако это нотребует более сложного синтаксиса: 


<$= НЕТ .ТехЕВох ("туЕехе", "уа1", 
пем 01сЕ1опаку<5:1тпа, ордес®> { { "с1аз5", "шусз5СТазз" } }) %> 


Замечание по поводу кодирования НТМЕ 


Наконец, следует отметить, что вспомогательные методы НТМГ, автоматически вы- 
нолняют НТМГ-кодирование значений полей, которые они визуализируют. Это очень 
важно, поскольку в противном случае приложение окажется уязвимым к атакам меж- 
сайтовыми сценариями (Х$5). 


Визуализация ссылок и ЦВЕ 


Следующий набор вспомогательных методов НТМ1Т, нозволяет визуализировать ссыл- 
ки НТМЕ и неформатированные ОБЕ, используя средство генерации исходящих ОВЕ 
системы маршрутизации (см. табл. 10.3). Вывод этих методов зависит от активной кон- 
фигурации маршрутизации. 

Во всех случаях, кроме 0х] .Сопеепе (), в гоикеУа]щез можно передавать промз- 
вольную коллекцию донолнительных нараметров маршрута. Такой коллекцией может 
быть Воифеуа1иер1сЕ1опагу или произвольный объект о5]есь (обычно анонимно ти- 
пизованный), в котором будут проверяться свойства и значения. 
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Таблица 10.3. Вспомогательные методы НТМЕ для визуализации ссылок и УВЕ 


Описание Пример 


ВЕ относительно приложения Вызов: 0т1 .СопсепЕ ("-/ту/сореет®.раЕ") 
Вывод: /ту/соптепе.раЕ 


Ссылка на именованное Вызов: НЕТ .АСЕТопГ Арк (тт ‚ "Ароце“, "Номе" )} 
действие и контроллер Вывод: <а нкеЕ=" /Ноте /Ароце">Н1</а> 


Ссылка на абсолютный УВЕ — Вызов: Нси1. .Асе1опТлюк("На", "АБосе", “Нопе", "ВЕЕрз", 


"ууги.ехатр1е.сот", "апсвог", пем{}, пи11) 
Вывод: <а НгеЕ="НЕЕрз: //мум.ехатр1е .сош/Ноше/АроцЕфатсвох"> 
Н1</а> 

Неформатированный ЦВЕ Вызов: 0х1 .АсЕ1оп ("АБОЦЕ", "Ноше") 
для действия Вывод: /Ноте /Ароце 
Неформатированный УВЕ Вызов: 0т1 .Восее0т1 (пем { сопЕхо11ет = "с", асЕ1оп = "а" }) 
для данных маршрута Вывод: /с/а 
Ссылка на произвольные Вызов: НЕт1 .Вопеет1ик("Н1", пем { сопеко1Тек = "с", 
данные маршрута асЕ1оп = "а" }, пи11) 

Вывод: <а ВгеЕ="/с/а">Н1</а> 
Ссылка на именованный Вызов: НЕ .ВоцЕе! 1 пк ("Н1", "туМатедВоцее", пем {}) 
маршрут Вывод: <а птеЕ=" /ик1 /Еок/патед/тгонее">Н1</а> 


Средство генерации исходящих ОВЕ в МУС Егате\уогК либо использует эти значения 
в самом пути ОВГ, либо добавит их как значения строки запроса, например: 


НЫ] .Асефор1 АК ("СЛаск пе", "МудАсЕлоп", пем {сорего]Лег = "Апобтег", рагаш = "уа1"}) 


В зависимости от конфигурации маршрутизации, этот вызов может визуализиро- 
вать следующий НТМГ-дескриптор: 


<а НгеЕ=" /АпоВег/МуАсЕ1оп?рагап=уа1">С11ск пе</а> 


Более подробную информацию о генерации исходящих ЧВГ ищите в главе 8. 


Кодирования НТМЕ-разметки и атрибутов 


Вспомогательные методы, перечисленные в табл. 10.4, предлагают быстрый способ 
кодирования текста, в результате которого браузеры перестают его интерпретировать 
как НТМГ-разметку. Это важное средство защиты от атак Х$$, о которых речь пойдет 
в главе 13. 


Таблица 10.4. Вспомогательные методы НТМЁ для кодирования 


Описание Пример 


Кодирование НТМЕ — Вызов: Неи1 .Епсоде ("Т'м <5>\"НТМЬ\"-епсоаед</ь>") 
Вывод: Т'ш &1Е;5806; вое; НТМЬбацое; -епсодея&1% ; /5 9; 


Минимальное Вызов: Нет . АСЕк1роееЕпсоде ("Т'м <>\"аЕЕк1Ьиее\"-епсодеа</ю>") 
кодирование НТМЕ Вывод; Т'ш &1%Е;5>банцоЕ; аб г 1робебаное ; -епсоаеа&1%; /©> 
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Внимание! Ни НЕп1 .Епсоде (), ни Ныт1 . АбсхлрасеЕпсоае (} не заменяют символ апостро- 
фа (') сущностным эквивалентном НТМЕ (&ароз;). Это значит, что их вывод нельзя помещать 
в атрибут НТМ!--дескриптора, ограниченный апострофами, даже несмотря на то, что это допус- 
тимо в НТМЕ. В противном случае введенный пользователем апостроф нарушит НТМЕ-разметку 
и сделает сайт уязвимым к атакам Х$$. Во избежание этой проблемы, при визуализации вво- 
димых пользователем данных в атрибуте НТМ!--дескриптора всегда заключайте атрибут в двой- 
ные кавычки, а не в апострофы. 


Обычно то, какой из этих двух вспомогательных методов выбирается. значения не 
имеет. Как показано в табл. 10.4, метод НЕи1 .Ерсоае (} кодирует более широкое множе- 
ство символов (включая угловые скобки), чем НЕш1 . АЕЕЕ1рофеЕпсоде (), однако в боль- 
итинстве ситуаций метода Нет] . АЕЕх1рисеЕпсоде () оказывается вполне достаточно. 
К тому же НЕт1. АбЕк1БабеЕпсоаде () работает быстрее, хотя заметить разницу сложно. 


Визуализация раскрывающихся списков 
и списков с множественным выбором 


В табл. 10.5 перечислены некоторые встроенные всномогательные методы для ви- 
зуализации элементов управления форм, содержащих списки данных. 


Таблица 10.5. Вспомогательные методы НТМЕ для визуализации элементов 
управления вводом с множественным выбором 


Описание Пример 


Раскрывающийся список Вызов: 
Нет .Охорроми[1 3 ("му 13", 
пем Зе1есеТ1зЕ(пем [|] {"А", "В"}), "Своозе") 
Вывод: 
<зе1есЕ 19="пу115" папе="ту115е"> 
<ор1оп уа1ие="">Своозе</орЕ1оп> 
<орЕ1оп>А</орЕ1оп> 
<орЕ1оп>В</орЕ1оп> 
</зе1ес®> 


Список с множественным — Вызов: 
выбором НЕ . Та зЕВох ("тут 8", 
пеи Ми115е1есеТ1з (пем [] {"А", "В"})) 
Вывод: 
<зе1есе 14="муЪ1зе" шо1е1р1е="то1Е1р1е" пвапе="му11$0"> 
<орЕ1оп>А</орЕ1оп> 
<орЕ1оп>В</орЕ1оп> 
</зе1есЕ> 


Как видите, оба метода НЕт1 .ПРхорроип11$() и НЁл1 .Г1$ЕВох() принимают зна- 
чения от объекта $е1ес®1 15% своего базового класса Мо1Е15е]ес+113%. Эти объекты 
позволяют описывать литеральный массив значений, как показано в табл. 10.5, или 
извлекать данные из коллекции произвольных объектов. Предположим, например, что 
имеется класс Вед1оп, определенный следующим образом: 


рУБ11с с1аз5 Вед1оп 

{ 
рур11с 116 Ведфоптр { дее; зе; } 
риб11с зЕг1па Вес1опМаме { дее; зе; } 
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Пусть метод действия помещает объект $е1ес&115% в У1емГата[" тед1оп"], как по- 
казано ниже: 


Т156<Вед1оп> гед1опзрага = пем ТАз%<Ведфоп> { 


реи Вед1оп { Ведлоптро = 7, Вед1опМате = "МогЕВеги" }, 
пени Ведфоп { Веслоптр = 3, Вед1опМаше = "“Сепега1" }, 
пеи Вед1оп { Веблоптр = 5, Вед1опМате = "Зочфвегп" }, 
}; 
У1емрафа ["гед1оп"] = пем Зе1есЕТ1 + (хед1опзрафа, // элементы 
"Вед1оптр", {/{/ ЗафаУа1щеЕ1е1а 
"Вес1опМапе", // аакаТехЕЕ1е1а 
3) // зе1естедУа1ле 


Тогда вызов <$= Не] .Ркорроипт1 8+ ("хед1оп", "Сноозе") %> визуализирует сле- 
дующий код (разрывы строк и отступы добавлены для ясности): 
<зе1ест 19="гедлоп" ваме="кеслоп"> 
<орЕ1оп уа1це="">Сроозе</орЕ1оп> 
<орЕ1оп уа1ще="7">МогЕНеги</орЕ1оп> 
<ОРЕ1оп зе1естеа-="зелестей" уа1ае="З">Сепека1</ор1оп> 
<орЕ1оп уа1ще="5">бопЕвеги</орЕ1оп> 
</зе1есе> 


Имейте в виду, что рассматриваемые здесь вспомогательные методы не должны ис- 
пользоваться только потому, что они существуют. Если проще выполнить итерацию но 
коллекции вручную, генерируя по ходу элементы <зе1есЕ> и <орЕ1оп>, то так и следует 
поступать. 


Дополнительные вспомогательные методы 
из сборки М: сгозоЕЕ. Иеь.Мус. а11 


В сборке АЗРМЕТ МУС Еибхез — МаскозоЕ+ . мер .Мус . 911 — содержится множест- 
во других всномогательных методов НТМЕ, которые в Мсгозой не сочли важными или 
достаточно отшлифованными, чтобы включить в комплект основной поставки МУС 
Егатехмогк, но которые могут быть полезны в ряде ситуаций. Эту сборка доступна для 
загрузки по адресу ими. соаер1ех.соп/азрие*. 

Прежде чем можно будет пользоваться этими вспомогательными методами, в про- 
ект нотребуется добавить ссылку на сборку МасгозоЕе .иеь .Мус.911, а также изменить 
файл имею. совпЕ1ч, чтобы это пространство имен импортировалось во все страницы 
представлений: 


<сопЕ1дагаЕ1оп> 
<зузбет.мер> 
<радез> 
<папезрасез> 
<а@а папезрасе="М1скозоЕ*.Меь.Мус" /> 
<!-- Остальные элементы не изменяются --> 
</патезрасез> 
</радез> 
</зузЕет.меЪ> 
</сопЕ1чикае1оп> 


После этого станут доступными дополнительные вспомогательные методы, которые 
перечислены в табл. 10.63. 


ЗВ сборке МтскозоЕс. Иер .Мус.а11 также содержится вспомогательный метод по имени 
Вад1оВиоп11 з® (), который должен работать подобно Ркорроип!1 3 (). В таблице этот 
метод не указан, потому что на момент написания книги он работал некорректно. 
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Таблица 10.6. Вспомогательные методы НТМЕ из сборки М1скозоЕЕ .МеЪ .Мус. 911 


Описание Пример 


Изображение Вызов: НЕ .АсЕлорТ1пК<НомесопЕко11ех> (х => х.Аройе(), "Н1") 
Вывод: <а НгеЕ=" /Номе/АБоц®" >Н1</а> 


Кнопка уамабспру Вызов: Н1 .Ма1160("Е-ша11 ще", "ме@ехатр1е.сош", "ЗаЮесе") 


Вывод; <а Вхе{="ща11{о:ме@ехатр1е . сош? за} есЕ=$ию]есё"> 
Е-па11 ше</а> 


Ссылка в виде Вызов: Нет. . Зал Ви боп ("51 1", "баба пом") 

лямбда-выражения Вывод: <1приё 14=" защ 1" паме="зо51141" фуре="зибиа Е" 
уа1ае="5иби1 пом" /> 

Ссылка для отправки Вызов: НЕ] .Ма11%0 ("Е-ма11 ше", "ме@ехатр1е.сош", "боЪ]есь") 


почтового сообщения Вывод: <а ВгеЕ="па11 0 :ме@ехатр1е . сом? за} еск=ЗЪ}ес"> 
Е-ща11 пе</а> 


Кнопка отправки Вызов: НЕ . баб Ва Еоп ("заб 1", "бабитЕ пои") 
Вывод: <1прис 19="за5161" папе="зиютз 1" Буре=" зори" 
уа1ае="бабт1 пои" /> 
Изображение отправки Вызов: Нем] . Зита ЕТмаде ("заБи12", "-/Ео1аек/1иа.91=") 


Вывод: <1при®ё 149="зибт1 2" папе="зиюи1 2" 
згс="/Ео1Чек/1то.91Ё" Буре="1таде" /> 


ЦАЕ в виде Вызов: НЫ] .Ви1190х1ЕхомЕхргез1оп<НошеСопко11ек> (х => 
лямбда-выражения х.Ароче ()) 


Вывод: /Номе/Абоче 


Внимание! Вспомогательные методы, генерирующие УАЕ и ссылки в виде лямбда-выражений, 
Нет .Асезтоп<Т> () И НЕТ .Ви1190х1ЕгомЕхргеззтоп<Т> (), обсуждались в главах 8 
и 9. Там объяснялось, что несмотря на их строгую типизацию, нельзя рассчитывать на их пра- 
вильную работу в сочетании с определенными механизмами расширения АЗРМЕТ МУС. Именно 
потому эти вспомогательные методы не включены в основной пакет АЗР.МЕТ МУС. В данном 
случае разумнее использовать вспомогательные методы, которые генерируют ЦВЕ и ссылки, 
основанные на обычных строках. 


В некоторых случаях использовать эти вспомогательные методы проще, чем писать 
соответствующий код НТМГ. Например, альтернативой НЕи1 .Тпаде () является следую- 
щий код: 

<1иа экс="<$%= ОкЪ.Сопееп® ("-/Ео1аег/1иа.а1Е") %>" /> 


Набирать эту строку не особенно удобно, потому что (во всяком случае, в версии 
Миа] Эбла1о 2008 с $Р1) средство НиеШЗепзе для АЗРХ просто отказывается работать 
во время ввода атрибута НТМГ-ескриптора. 

Однако вызовы некоторых из этих вспомогательных методов набирать действитель- 
но труднее, чем соответствующий код НТМГ,, что не дает оснований для их использо- 
вания. Например, зачем писать вызов 


<%= Неп1 . бара ЕВаеоп ("зопетр", "баби1е пом") %> 


если маловероятно, что кнопке отправки понадобится назначать идентификатор. 
Вместо такого вызова можно просто записать следующий НТМГ-дескриптор: 


<1приё фуре="зиют1" уа1ае="бабите пом" /> 
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Другие вспомогательные методы НТМЁЕ 


Для полноты картины в табл. 10.7 перечислены остальные встроенные вспомога- 
тельные методы НТМГ. которые ранее не упоминались. Они более подробно описаны в 
других местах книги. 


Таблица 10.7. Другие вспомогательные методы НТМЕ 
а 


Метод Примечания 


НЕ . ведфпЕРоги () Визуализирует открывающий и закрывающий дескрипторы <Еоги>. 

(См. раздел “Визуализация дескрипторов <Еотт>” далее в этой главе.) 
НЕт1 .ВепдекАс®1оп (), Выполняет независимый внутренний запрос в сборке МтскозоЕ+Е.Меь. 
НЫ] .Вепдегвопее () Мус . 911, встраивая полученный ответ в вывод текущего запроса. 


(См. раздел “Использование НЕт1 .ВепаехгАсь1оп для создания мно- 
гократно используемых графических элементов с прикладной логикой" 
далее в этой главе.) 

НЕ] .ВепаегРаг1а1 () Визуализирует частичное представление. (См. раздел “Использование 


частичных представлений" далее в этой главе. } 


НЕта .Уа13 да 1опмеззаде () — Визуализирует сообщение об ошибке проверки достоверности для опреде- 
ленного свойства модели. (См. раздел “Проверка достоверности” в главе 11.) 


Нет] .Уа1да®1опбиттату () — Визуализирует итоговую информацию обо всех ошибках проверки досто- 
верности. (См. раздел “Проверка достоверности” в главе 11.) 


Нет] .АРЕТЕотаекуТокеп () — Пытается блокировать атаки меж-сайтовым запросами (СЗЕР). (См. раз- 

дел “Предупреждение атак СЗВЕ с помощью противоподделочных вспо- 

могательных методов” в главе 13.) 
м 

Имеется также ряд вспомогательных методов, связанных с Аах, например, А]ах. 

АсЕетопГ1иК (); они рассматриваются в главе 12. В строго типизированных представ- 
лениях также могут использоваться обобщенные вспомогательные методы ввода МУС 
Еибогез, такие как Нет] .ТехЕВохЕгок<Т> (). Однако на момент написания книги они 
существовали лишь в виде ранних прототипов. 


Визуализация дескрипторов <Еогт> 


В МУС ЕгатехогК также предоставляются вспомогательные методы для визуализа- 
ции дескрипторов <Еогш>: НЕт1 .ВедлпЕоки() и Нем1.ЕпдЕокги (). Преимущество их 
применения (вместо написания дескрипторов <Еоги> вручную) состоит в том, что они 
генерируют соответствующий атрибут асЕ1оп (те. ОКТ, на который будут отправлены 
данные формы) на основе активной конфигурации маршрутизации и выбранного целе- 
вого контроллера и метода действия. 

Эти вспомогательные методы НТМИ, слегка отличаются от показанных ранее: они 
не возвращают 5&х1п9. Вместо этого записывают разметку дескрипторов <РЕоги> и 
</Гоги> непосредственно в поток ответа. 

Доступны два способа их использования. Метод Неп1.ЕпбЕоги() можно вызвать 
явно, как показано ниже: 

<% НЕпТ.Вед1пРоги ("МуАСЕ1оп", "МуСопЕго11ех"); %> 

. элементы формы ... 
<% НЫп1.ЕпаЕоги(); %> 


Кроме того, метод НЕш1.Вед1пЕоги() можно поместить внутрь оператора и$1п9: 


<$ 15119 (НЕ1 .ВестпЕоки ("МуАсЕ1оп", "МуСопЕго11ек")) { $%> 
..- Элементы формы ... 
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Эти два фрагмента кода производят одинаковый вывод, так что можете использо- 
вать тот синтаксис, который больше нравится. При конфигурации маритрутизации по 
умолчанию вывод будет таким: 


<Еоги асе1оп=" /МуСопетхо11ег/МуАсЕтоп" шефвод="розе"> 


... элементы формы ... 
</Еохгт> 


Если не понятно, как работает второй синтаксис, вот пояснение. Метод НТ. 
Вед1пЕоги() возвращает объект тр1зрозаБ1е. Когда он уничтожается (в конце блока 
031109), его метод Р1зрозе() записывает закрывающий дескриптор </Гогт> в поток 
ответа. 

Чгобы указать другие параметры маритрутизации для атрибута ас1оп в ОВГ. формы, их 
можно передать в качестве третьего, анонимно типизированного параметра, например: 

<$ Нем .ВедуиЕоги ("МуАсЕ1оп", "МуСопего11ег", рем { рагам = "дла" ла» 

Этот вызов визуализирует следующий код: 


<Еоги асё1оп=" /Мубопего11ет/МуАсЕ1оп?рагап=уа1" мефвоа="розе"> 


На заметку! Если необходимо визуализировать форму с атрибутом асЕ1оп на основе именован- 
ного элемента маршрута или произвольного набора данных маршрутизации (например, без 
специальной интерпретации параметров сопЕго11ег ИЛи асё1оп), можно воспользоваться 
методом НЕ1 .Вед1пБосееЕоги(). Он представляет собой эквивалент вспомогательного 
метода НЕт1 .ВопкеГлик () ‚ генерирующего форму. 


Формы, выполняющие обратную отправку тому же самому имени действия 


Если опустить имя контроллера или действия в вызове вспомогательного метода, 
то он сгенерирует форму, которая отправит данные обратно ОВ! текущего запроса. 
Например: 

<% ц51п9 (Нм .Вед1пЕоги()) { %> 

... элементы формы ..- 


Резульгат визуализации выглядит следующим образом: 


<Рога асЕ1оп="ОВЬ текущего запроса" шебвод="розе" > 
. элементы формы ... 
</Еоги> 


Использование метода НЕ] .Вед1пКоги<т> 


Сборка М1скозоЕе .Меь.Мус.911 содержит обобщенную перегрузку Нет! .Вед1оРогт<Т> (), 
которая для ссылки на целевое действие позволяет использовать строго типизированное 
лямбда-выражение. Например. если имеется класс контроллера РтодисеСопеко1Тек с 
подходящим методом действия 5иБи1{Ед1еедРгкодис® ($г1п9 рагам) , его можно вы- 
звать так: 


<% изупа (НЫ. .ВедлпЕоги«РГобисезСопеко1Тек> (х => х. зори ЕЕЧЕЕеаРко@ись ("ха1ае"))) { %> 
... элементы формы ... 


На заметку! Для того чтобы приведенный код работал, странице АЗРХ необходима ссылка на 
пространство имен, содержащее Ркобисе$Сопего1Тек. Добавьте в начало страницы АЗРХ 
объявление <3@ ТирогЕ Мапезрасе="Ваши. Контроллеры. ПространствоИмен" %> 
(в дополнение к ссылке на сборку М1скозоЕЕ .Меь.Мус). 
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В результате визуализируется следующий код разметки (на основе конфигурации 
маршрутизации по умолчанию): 


<Еоги асЕ1оп=" /Рко@исе$ / ЗаБи1ЕЕЯ1 еаРгодисе?раган=уа1ае" песвоЯ="розе" > 
... Элементы формы ... 
</Еоги> 


Строго типизированный вспомогательный метод Неш1. Вед1пЕоги<Т> () подчиня- 
ется тем же ограничениям, что и НЕт1.АсЕ1опЬ1тК<Т>(). К тому же имейте в виду, 
что для того, чтобы сформировать корректное лямбда-выражение, понадобится ука- 
зать значения для каждого параметра метода, который визуализируется как параметр 
строки запроса в ЧВГ. Но это не всегда имеет смысл: иногда нужно, чтобы параметры 
метода действия были привязаны к полям формы, а нек параметрам строки запроса. 
Обходной путь заключается в передаче фиктивного значения пи11 для каждого нежела- 
‘тельного параметра, но и это не будет работать, если параметр имеет тип, не допускаю- 
щий значение по11, скажем, 1пе. Будущая версия языка С# 4.0 должна поддерживать 
динамические вызовы методов и необязательные параметры, так что можно ожидать 
появления более очевидного АРГ-интерфейса. 

По этим причинам, а также из-за трудоемкости добавления к страницам объявлений 
<%@ ТпрокЕ %>, рекомендуется по что избегать метода Нет]. Вед1пЕоги<Т> () и приме- 
нять вместо него НЕш1 .ВедтиЕоким(). 


Создание собственных вспомогательных методов НТМЕ 


Во встроенных вспомогательных методах нет ничего сложного или мистического. 
Это просто методы .МЕТ. возвращающие зЕк1п9д, так что можете свободно добавлять в 
приложения собственные вспомогательные методы. 

Например, давайте создадим вспомогательный метод, который визуализирует деск- 
рипторы <$сг1рЕ> для импорта файлов Зауа$ сре. Создайте новый статический класс 
по имени МуНе1регз (скажем, в файле /У1еиз/МуНе1рег$.с3]): 


папезрасе ПептоРго)есе.У\У1еиз 
{ 
рур11с эсаЕ1с с1азз МуНе1регз 
{ 
рглуафе сопзЕ зёк1па Зскфретистадегогиае = "<зсгтрёе зкс=\" {0}\"></зск1рЕ>"; 
руЮ11с збаё1с зЕклпа ГисТоаезскт ре (зЕк1па У1уЕла1Раен) 
{ 
зЕг1по с11еперафНВ = У1тгсаа1РаЕВ0Е1116у. ТоАБзо1 асе (у1хЕаа1Рафн); 
гегагп зЕк1па.Еогвае (5скареТпс1ааеЕогцае, с11епЕРаеВ); 


} 


На заметку! Следуя хорошей традиции, этот вспомогательный метод работает с виртуальными пу- 
тями, т.е. с такими, которые начинаются с -/ и указываются относительно корня виртуального 
каталога приложения. Виртуальный путь преобразуется в абсолютный во время выполнения (с 
помощью метода У1гЕца1Ра 01116 у.ТоАБзо1 ее () }, с учетом виртуального каталога, 
в котором развернуто приложение. 


После компиляции новый вспомогательный метод можно использовать в любом 
представлении, указывая его полностью определенное имя: 


<%= РепоРго]есё.У1еиз .МуНе1регз. Тастадеб сет ре ("-/5сктрез/боме$ск1ре.)з") %> 
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Этот вызов визуализирует следующий код: 
<вск1ре згс="/бск1рез/ботебск1ре. 5"></зст1ре> 


Если приложение развернуто в виртуальном каталоге. то это будет учтено в соответ- 
ствующем атрибуте эгс. 

Если нет желания каждый раз писать полностью определенное имя вспомогательно- 
го метода каждый раз, можно импортировать его пространство имен двумя способами. 


»® Добавить директиву 1прогЕ вначалокаждой страницы представления, где использу- 
ется этот метод (например, <%@ ТирогЕ Машезрасе="РетоРко]есе.У1еиз" %>). 


® Импортировать пространство имен на все страницы, добавив новый дочерний 
узел под узлом зузееш. ие /радез/пашезрасез в файле меЪ .сопЕ1д (например, 
<а4Я папезрасе="рРетоРгоес®.\У1емз" />). 


В любом случае, вызов метода затем может быть сокращено до следующего: 


%= Муне1регз. Тпс1аде5ск1р® ("-/5сх1рез/бощебск1ре.]з") %> 


Присоединение собственного вспомогательного метода 
к НЕш1Не]1рег через расширяющий метод 


Возможно, понадобится превратить вспомогательный метод в расппиряющий метод 
типа Нет1Не1рек, сделав его подобным одному из встроенных вспомогательных мето- 
дов. Для этого измените сигнатуру метода следующим образом: 


рчБЛас эае1с зЕгупа ТасТтадебск{ре (ЕВ15 Нып1Не1рек Ве1рег, зЕгапд у1коа1ТРаЕВ} 
{ 

зЕк1па с11епЕРабн = У1геиа1РаЕВ0е111у.ТоАрзо1лаее (у1к(оаа1РаЕП); 

тефигп зЕг1па.Еогмаф (ЗскареТпсТтадегогтае, с11епЕРа®в); 


} 


Теперь вспомогательный метод становится членом клуба НЕш1 .*, и его можно будет 
вызывать так: 


<%= НЫпт.ТиосТтаде$ск1р® ("^/бсгарЕз/бопебск1ре.)8") %> 


Обратите внимание, что расппиряющий метод будет доступен только в представлени- 
ях, в которые было импортировано пространство имен статического класса с использо- 
ванием одного из описанных ранее приемов. Формально это ограничение можно обойти, 
поместив статический класс прямо в пространство имен 5узеетм.меь .Мус .Неш1, но это 
запутает и вас, и других разработчиков. поскольку трудно будет отслеживать, где ваш 
код, а где код, относящийся к платформе. Не посягайте на чужие пространства имен! 


Использование частичных представлений 


Нередко возникает потребность многократно использовать фрагмент представления 
в нескольких местах. Не обращайтесь к технике “копирования и вставки”, а выделите 
его в частичное представление. Частичные представления подобны специальным вспо- 
могательным методам НТМЕ, за исключением того, что они определены с использова- 
нием выбранной системы шаблонов представлений (те. файлов АЗРХ или АЗСХ, а не 
чистого кода С*#) и потому больше подходят, когда планируется повторно использовать 
более крупные блоки разметки“. 

В этом разделе вы узнаете о том, как создаются и используются частичные пред- 
ставления в стандартном механизме \еБЕогип$, и ознакомитесь с различными метода- 


“Частичные представления АЗРМЕТ МУС логически эквивалентны тому, что в ВиБу т КаП$ 
и МопоКай называют “частичными шаблонами”. 
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ми их применения с Узеирата и привязками к спискам или массивам данных. Прежде 
всего, обратите внимание на параллели между частичными представлениями и обыч- 
ными представлениями. 


® Точно так же, как страница представления является страницей \еЕогиз$ (те. 
шаблоном А$РХ}), частичное представление является пользовательским элемен- 
том управления \еЪЕогтиз$ (те. шаблоном АЗСХ). 


® Страница представления компилируется в виде класса, унаследованного от 
У1еиРаде (который, в свою очередь. наследуется от ОзегСоп+го1, базового клас- 
са для пользовательских элементов управления У/еБЕогил$). Промежуточные ба- 
зовые классы добавляют поддержку специфичных для МУС нотаций, таких как 
Утемрака, Тепррака и вспомогательных методов НТМИ. (НЕп1.*, 0к1.* итп.). 


® Страницу представления можно сделать строго типизированной, наследуя ее от 
УТеиРаде<Т>. Аналогично, частичное представление тоже можно сделать стро- 
го типизированным, унаследовав его от У1еи0зегСопего1<Т>. В обоих случаях 
свойства У1еирата, НЕш1 и Адах заменяются обобщенно типизированными экви- 
валентами. При этом свойство Моде1 будет относиться к типу Т. 


Создание частичного представления 


Для создания нового частичного представления щелкните правой кнопкой мыши на 
какой-нибудь папке внутри /У1еиз и выберите в контекстном меню пункт Ааа» \е\м 
(Добавить=>Представленис). В открывшемся окне Ада \Ме\м (Добавить представление) от- 
метьте флажок Сгеае а рагда! Ме\ (.азсх) (Создать частичное представление (. азсх))- 
В МУС ЕгатехогК предполагается, что частичные представления будут сохраняться в 
папке /У1емз/имяКонтроллера или /У1еиз/51агесд, но в действительности их можно 
поместить куда угодно и затем ссылаться на них по полному пути. 

Например, создайте частичное представление по имени МуРаг+1а1 внутри /У1ечз/ 
Зпагед и затем добавьте к нему некоторую НТМГ-разметку: 


<$@ Сопфго1 Тапдиаде="С#" Тирег1+5="бузфем. Мер .Мус.УлеиОзегСопего1" $> 
<1>Не11о Екош ЕВе рак+1а1 у1ем</1> 


Чтобы визуализировать частичное представление, перейдите на любую страницу 
приложения и вызовите вспомогательный метод НЕпи1.кепдегРакЕ1а1 (), указав имя 
частичного представления: 


<р>ТН1з 15 ЕВе сопЕа1пег улеи</р> 
<$ НЕм1 .ВепдекРак+1а1 ("МуРак+1а1"); %> 
<р>Неге'з Ее сопеазпег у1еи адалп</р> 


В резульгате визуализируется вывод, показанный на рис. 10.2. 
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Рис. 10.2. Вывод представления, оснащенного частичным представлением 
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На заметку! Обратите внимание на синтаксис, окружающий вызов НЕм1 .ВепдехгРагЕ1а1 (). Этот 
метод возвращает не зЕг1пд, а уо1а, и отправляет свой вывод непосредственно в поток отве- 
та. При этом вместо вычисления выражения (как в <%= ... %>) фактически выполняется стро- 
ка кода С# (потому в <% ...; %> присутствует точка с запятой, завершающая строку кода). 


Для визуализации частичного представления, которое находится не в /У1емз/ 
патеоЕСопеко11ег или /\У1еиз/5ваге@, понадобится указать виртуальный путь цели- 
ком, включая расширение имени файла. Например: 


<% НЕи1.ВепаегРаг®1а1 ("-/У1еиз/брагеЯ/РагЕ1а1$/МуОВегРак(1а1.азсх"); %> 


Передача Узеирака в частичное представление 


Подобно обычным шаблонам представлений, частичные представления имеют 
свойство У1еирафа. По умолчанию это просто прямая ссылка на объект контейнера 
У1еирака. Это означает, что частичное представление имеет доступ к тому же набору 
данных — как к содержимому словаря, так и к объекту У1емраса.Моде1. 

Предположим, например, что метод действия заполняет У1е ака ["пеззаде"], как 
показано ниже: 


ру11с с1азз НозСопЕго11ех : Соп®ко11ек 


{ 
ру611с УлемВезо1® Тпаех (} 


{ 


Утемраба ["пеззаде"] = "Сгее®1тоз"; 
// Теперь визуализировать страницу представления, 
// которая визуализирует МуРагЕ1а1.азсх 
теёокп Улеи(); 
} 


Тогда МуРаг{1а1 .азсх автоматически разделит доступ к следующему значению: 


<%@ СопЕго1 Гапотаде="С{" АбоЕуепЕИ1кеир="Егие" СодеВер1та="МуРакг®1а1 .азсх.с®" 
Тибег1 6 з="МуАрр .У1еиз .бвагеа.МуРагЕ1а1" %> 
<1><$%= Уземраба["шеззаде"] %> Егом Ве ра’Еза1 узеи</1> 


Результирующий вывод показан на рис. 10.3. 


хлосетсусУ С РБИНозк - Мйпаслиз Бета" Ехренег 


Рис. 10.3. Частичные представления могут иметь доступ к элементам У1емрака 


Эта техника работает хорошо, но создает некоторое некомфортное ощущение от 
того, что дочернее частичное представление имеет доступ ко всей родительской коллек- 
ции У1еирафа. Разумеется, частичное представление заинтересовано только в подмно- 
жестве этих данных, так что имеет смысл предоставить доступ только к нужным дан- 
ным. К тому же, при визуализации множества экземпляров определенного частичного 
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представления, когда каждый экземпляр должен отображать свои данные, необходим 
какой-нибудь способ передачи разных элементов данных в каждый экземпляр. 


Передача явного объекта У1еирака .Мо4е]1 
в частичное представление 


Доступна перегрузка метода НЕт1 .ВепдегРаге1а1 (), которой при вызове можно 
передать значение во втором параметре поае1, и оно станет объектом Моде1 частично- 
го представления. Обычно эту перегруэку необходимо использовать при визуализации 
строго типизированного частичного представления. 

Пусть, например, контроллер помещает объект Регзоп в У1еирака: 


риБ11с с1азз Регзоп 
{ 
руБ11с 5Ег1па Маше { деф; зеф; } 
руБ11с 10Е Аве { деЕ; зес; } 
} 
руБ11с с1азз НозЕСопЕко11ек : СопЕко11ег 
{ 
руЮ11с УзеиВезиа1е Тпаех() 
{ 
Узеира{фа ["зоперегзоп"] = пем Регзоп { Маме = "Мадате", Аде =2 }; 
тебиахгп У1еи(); 


} 


Тогда при визуализации частичного представления можно выбрать и передать толь- 
ко это специфическое значение. Давайте визуализируем частичное представление из 
показанного выше представления действия Тпдех: 


ТЬ1з 13 ЕНе Во$Е раде. Ива Ео11оиз 15$ а рагЕ1а1 у4ем: 
<ь> 

<% НЫй1 .ВепдегРаг1а1 ("РегзопТоЕо", У1еирафа["зомерегзоп"]); %> 
</5> 


Теперь предположим, что в /У1еиз/5Ъагед/РегзопТиЕо.азсх имеется частичное 
представление, унаследованное от У1еи0зекСопеко1<Регзоп> и содержащее следую- 
щий код; 

<%@ СопЕго1 Тападцаде="с4" 


Тпрек Е з="бузбет. Мер .Мус .УлеОзекСопеко1<Приложение. ПространствоЙмен.Регзоп>" %> 
<%= Моде1 Маше %> 15 <$= Мо4е1.Аде %> уеагз 01а 


В резульгате будет визуализирован вывод, показанный на рис. 10.4. 

Как видите, значение, переданное методу НЕп1 .ВепдегРаг%1а1 () в виде парамет- 
ра шоде1, становится объектом Моде1 для частичного представления. Помните, что в 
шаблоне представления Моде1 является лишь сокращением для Узеирата .Моде1, где 
У1еирата — структура данных, содержащая набор сущностей словаря наряду со спе- 
циальным значением У1еирафа .Модет. 
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Рис. 10.4. Частичное представление визуализирует явно переданный объект Моде1 
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Совет. При передаче явного объекта Моде1 частичное представление утрачивает доступ к любой 
другой части коллекции У1емрафа родительского представления. Словарная часть структуры 
\У1еираба дочернего частичного представления будет пустой, а заполненным окажется лишь 
свойство Модет1. Если частичному представлению необходимо передать и словарь У1емрРаза, 
и объект Моае1, применяйте перегрузку НЕм1 .ВепдегРахЕ1а1 () , которая принимает пара- 
метр У1емаЕар1сЕ1опаху. 


Визуализация частичного представления для каждого элемента коллекции 


Во время визуализации частичных представлений Ргодисе Зилииакгу.азсх в главе 4 
было показано, что организовать для каждого элемента коллекции визуализацию от- 
дельного частичного представления довольно просто. Пусть, например, в методе дейст- 
вия подготавливается коллекция 11$5$<Регзоп>: 


рую11с УлеиКеза1е Тпаех () 
{ 


\У1емрафа|["реор1е"] = пем Т1зЕ<Регзоп> { 
пеи Регзоп { Маше = "Агср1меаез", Аде = 8 }, 
пеи Регзоп { Маше = "Аг1з®о1е", Аде = 23 }, 
пем Регзоп { Маме = "Аппафе11е", Аде = 75 }, 


}; 
хееагп У1ем(); 


) 


Шаблон представления может выполнить итерацию по этой коллекции и визуализи- 
ровать отдельное частичное представление для каждого элемента: 


Вот список людей: 


<01> 
<% Еогеасй(уагк регзоп 1п (ТЕпимегаю1е) У1еирата ["реор1е"]) %> 
<11> 
<% Нёи1.ВепаетгРагЕ1а1 ("РегзопТтЁо", регзоп); %> 
</11> 
<% } %> 
</01> 


Результирующий вывод показан на рис. 10.5. 

Большинство программистов АЗР.МЕТ МУС отдают предпочтение старому доброму 
циклу ГогеасН и не используют шаблонные элементы управления и механизм привяз- 
ки данных, преобладающего в АЗРМЕТ \еБЕогтз. Цикл ЕогеасНн предельно прост, не 
требует обработки специального события ОпрафаВоцп@ () и позволяет редактору кода 
предоставлять все функции НиеШ$епзе. Однако если вы привыкли к старому стилю ко- 
дирования \\еЪЕогил$, можете применять привязку данных, как будет показано ниже. 
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Рис. 10.5. Последовательность частичных представлений, каждое 
из которых визуализирует отдельный объект модели 
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Визуализация частичного представления 
с использованием серверных дескрипторов 


В качестве альтернативы применению НЕп1.ВепдегРат®1а1() можно встраивать 
частичное представление в страницу родительского представления, зарегистрировав 
элемент управления как серверный дескриптор. Если вы работали с АЗРМЕТ \еБЕогиз, 
то вам уже приходилось использовать эту технику ранее. 

Добавьте объявление <%@ ведазеег %> в начало страницы представления, указав 
частичное представление, которое должно быть доступно, а также специальный пре- 
фикс и имя дескриптора. Это объявление можно поместить в самое начало файла АЗБХ, 
как перед, так и сразу после объявления <%@ Раде %>. Например, добавьте следующее 
объявление: 

<%@ Вед15фег ТадРгеЁ1х="МуАрр" ТадМапе=“"МуРаге1а1" 

$кс="-/У1еиз/5Вагеа/МуРаг%1а1.азсх" %> 


Это сообщит компилятору АЗРХ, что при использовании дескриптора <МуАрр :МуРаг1а1 
хопа*="зекуег"/> необходимо визуализировать /У1еиз/5пагеб/МуРахгк1а1.азсх. 
Обратите внимание, что добавлять кипае="зекуек" обязательно. Без этого компиля- 
тор АЗРХ не будет трактовать его как специальный дескриптор, а просто отправит его 
в браузер в виде обычного текста. 

После этого можно писать <«МуАрр:МуРагЕ1а1 гирае="зекуек" /> где угодно в пред- 
ставлении, и частичное представление будет визуализировано в этом месте. Данный 
подход не так удобен и аккуратен, как применение Н{и1 .ВепаегРакЕ1а1 (), поэтому он 
рассматривается лишь вкратце. 


На заметку! Ранее уже было показано, как обрабатываются такие серверные элементы управ- 
ления во время компиляции и во время выполнения. Когда в начале этой главы приводился 
декомпилированный класс АЗРХ, вы наверняка обратили внимание, что серверные элементы 
управления становятся переменными-членами в скомпилированном классе страницы. Метод, 
визуализации элемента управления вызывается в соответствующей точке метода визуализации 
родительской страницы. 


Передача элементу управления структуры У1еирака 


Если частичное представление визуализируется с использованием специального 
серверного дескриптора, это частичное представление опять по умолчанию наследует 
всю структуру данных У1еирафа родительской страницы, те. как содержимое словаря, 
так и объект Моде1. Фактически, при наличии иерархии серверных элементов управ- 
ления в стиле \е Е огтз любое частичное представление МУС сканирует его цепочку 
предков, чтобы найти первый, который предоставит структуру данных У1емрака (те. 
первый, в котором реализован интерфейс ТУ1еирасаСопеа1пег). 


Явная передача элементу управления объекта УтеираЕа.Мо4е1 


Когда частичное представление визуализируется с применением специального сер- 
верного дескриптора, можно явно передать объект Моде1, указав для дескриптора ат- 
рибут по имени У1еирасаКеу. 

Например. предположим. что зарегистрировано строго типизированное частичное 
представление РегзопТпЕо (из предыдущего примера) с использованием следующего 
объявления: 


<%@ Бед1зфег ТадРтеЕзх="МуАрр" ТадМаме="РегзопТоЕо" 
Зхс="-/Утеиз/5ВагеЯ/РегзопТи{о.азсх" %> 
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Тогда визуализировать его можно путем передачи параметра \1еиратаКеу, как по- 
казано ниже: 


<МуАрр:РегзопТпЕо гипае="зегуег" У1емрафаКеу="регзопдафа" /> 


Предполагая, что контроллер уже заполнил У1емраба["регзопдафа"] некоторым 
подходящим объектом, этот объект станет объектом Моае1 дочернего частичного пред- 
ставления (при этом словарная часть структуры У1ерафа дочернего представления 
будет пустой). 


Совет. Внутренне М\УС Егате\могК для нахождения объекта модели для частичного представления 
вызывает метод У1емРафа.Еха1 ("параметрУтеирРаёаКеу"). Это значит, что здесь можно 
использовать нотацию разделенных точками лексем, принятую в Еха1 (), или ссылаться на 
свойства объекта Моде1 представления контейнера. 


Данный подход работает хорошо, если визуализируется только один экземпляр эле- 
мента управления и передается элемент словаря У1еПафа, который всегда имеет из- 
вестный фиксированный ключ. Развивая этот подход дальше, можно даже использовать 
привязку данных в стиле АЗРМЕТ \еБЕогтлз для визуализации последловательности час- 
тичных представлений, каждое из которых имеет свой объект Моае1, за счет приме- 
нения элемента управления <азр :Вереаеег>. Такое делается нечасто, и выглядит оно 
примерно так: 


<азр:Вереасетг Тр="МуВереафег" гопаЕ="зегуег"> 
<ГЕепТепр1аее> 
<МуАрр:РегзопТпЕо гипа&="зегуег" 
\У1еРафаКеу='<%# "реор1е@1сЕ." + Еуа1 ("Кеу") %>'/> 
</тЕешТетр1а®е> 
</азр:Кереабег> 
<зсг1рЕ гопаЕ="зегуег"> 
// Грубый прием! Встраивание обработчика событий МеБГогтз 
// в представление МУС... 
ргофесфеа уо1А Раде Тоа@ (ою]ес® зепдег, ЕхепЪАгаз е) 
{ 
МуВереафег.РафаЗоигсе = Улемрафа ["реор1ед1с®"]; 
МуВБереафег.РатаВ1па (); 
} 
</зсг1рЕ> 


В этом коде предполагается, что контроллер уже поместил объект ТР1сЕ1опагу< 
ЗЕг1па, Регзоп> в Утемрафа["реор1е91се"] (м это должен быть словарь, а не просто 
список или массив, так как нужно иметь возможность обращаться к каждому элементу 
по имени, а не по индексу). 

Согласитесь, что такой способ привязки данных грубый, причудливый и неприят- 
ный. Он был показан только потому. что множество новичков АЗРМЕТ МУС спрапгива- 
ют, как это можно сделать, и тратят массу времени на то, чтобы с ним разобраться. Не 
поступайте подобным образом! Гораздо проще воспользоваться следующим подходом: 


<$ ЕогеасЪ (уаг регзоп 1п (ТЕпииегар1е) У1емрафа ["реор1е"])} { %> 
<$ НЕи.ВепаегРаг&1а1 ("Регзоп1пРо", регзоп); %> 
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Использование НЕм1 .ВепдегАсе1оп 
для создания многократно используемых 
графических элементов с прикладной логикой 


Все повторно используемые конструкции, подобные элементам управления, которые 
вы видели до сих пор — встроенный код, вспомогательные методы НТМГ, частичные 
представления — замечательны для генерации НТМГ-разметки. но ни одна из них не 
подходит для размещения прикладной логики. Когда требуется реализовать приклад- 
ную логику или работать с моделью предметной области приложения, лучше отделить 
эту ответственность от механизма визуализации НТМГ, — это повысит читабельность и 
тестируемость создаваемого приложения. 

Каким же образом реализовать некоторый графический элемент5, расположенный 
в углу страницы и визуализирующий определенные данные независимо от остальной 
части контроллера? Речь идет о таких вещах. как элементы управления навигацией или 
панель биржевой информации. Как такой элемент получает свои данные, и если он дол- 
жен их обрабатывать каким-то образом, то куда поместить соответствующую логику? 

В этом разделе будут показаны возможные варианты использования для этих целей 
мощного вспомогательного метода НТМГ. по имени НЕп1 .ВепаекАсЕ1ол (). После этого 
будут представлены еще несколько возможностей. 


На заметку! В выпуске АЗР.МЕТ МУС 1.0 метод НЕим1 .ВепдекАсЕ1 оп () входит в состав сбор- 
ки МУС Риёигез (МтскозоЕЕ. Мер .Мус . 911). Это означает, что он как может быть вклю- 
чен в основной комплект будущей версии, так и нет, в зависимости от того, какая стратегия 
будет выбрана для реализации повторно используемых графических элементов. В любом 
случае, поскольку доступен исходный код, можно сохранить контроль над использованием 
НЕи1.РепЧегАсет1оп () как сейчас, так и в будущем. 


Чтобы можно было пользоваться методом НЕи1 .ВепаегАсе1ол (), в проект потребу- 
ется добавить ссылку на сборку М1 скозоЕЪ ._Мер.Мус . 911, а в файл ме. сопЕ1а — ссыл- 
ку на следующее пространство имен, чтобы все файлы АЗРХ и АЗСХ могли получить 
доступ к нему: 

<сопЁЕ1дикае1от> 

<зузбеп.меб> 
<радез> 
<папезрасез> 
<аЯЯ папезрасе="М1скозоЕ® .Меь.Мус" /> 
</памезрасез> 
</радез> 
</зузфет.меб> 
</сопЕ1дака1оп> 


Е Нестандартный термин графический элемент вместо термина элемент управления исполь- 
зуется здесь намеренно, во избежание впечатления, что он должен вести себя подобно сер- 
верному элементу управления \еБЕогил$ или элементу управления УЛпао\з Еогте. В част- 
ности, не следует рассчитывать на двунаправленное взаимодействие между пользователями 
и такими графическими элементами, потому что в АЗРМЕТ МУС код представления просто 
занимается генерацией НТМГ-разметки и не обрабатывает взаимодействие с пользователем. 
Для обеспечения насыщенного пользовательского взаимодействия в АЗРМЕТ МУС понадобит- 
ся найти готовый или создать новый элемент управления клиентской стороны (например. 
средствами Адах). Это обеспечит пользователям максимально возможный уровень комфорта. 


Глава 10. Представления 343 


Назначение метода НЕт1 .ВепаегАсе1оп 


Концепция, положенная в основу метода НЕп1.ВепдекАсетоп (), очень проста: он 
может вызывать любой метод действия в приложении и встраивать его вывод в ответ 
НТМЕ. 

Это позволяет передавать любой набор параметров в целевой метод действия. В их 
число входят произвольные параметры маршрутизации, потому что внутри он запуска- 
ет весь конвейер запроса-ответа МУС, начиная с вызова фабрики контроллеров с подго- 
товленной структурой Боцтерака (обзор конвейера МУС можно найти в главе 7). 

Поскольку в общем случае методы действий допускают произвольную логику, фильг- 
ры и шаблоны представлений, поддерживают инверсию управления (оС) через специ- 
альную фабрику контроллеров, являются тестируемыми и т.п., то все эти возможности 
остаются доступными. Целевой метод действия служит повторно используемым графи- 
ческим элементом, даже без необходимости знать, что он это делает. Простой и очень 
мощный подход! 

Вспомните, что мы использовали метод НЕп1 .ВепдегАсЕ1ол () для создания и меню 
навигации, и графического элемента итоговой суммы корзины покупок в примере раз- 
работки приложения Зро[зЗге в главе 5. 


Когда стоит использовать метод НЕт1 .Веп4егАсЕ1оп 


Метод НЕг1 .Веп4екАсЕ1оп () вызывается из шаблона представления и, в свою оче- 
редь, вызывает контроллер. С точки зрения МУС это может показаться шагом назад. 
Зачем шаблону представления вызывать контроллер? Разве представления не должны 
подчиняться контроллерам? Если вы приняли архитектуру МУС как догму. а не по праг- 
матичным соображениям, идея использования метода Ни1 .ВепаекАсЕ1 опт () может 
показаться незаконной. Но давайте обратимся к прагматичной точке зрения, и примем 
во внимание разделение ответственности. 


® Если целесообразно, чтобы контроллер поставлял графическому элементу дан- 
ные, которые должны быть в нем визуализированы, необходимо позволить ему 
это делать и затем использовать частичное представление для визуализации дан- 
ных в виде НТМГЕ. Например, для организации ссылок на страницы внизу экран- 
ной сетки контроллер должен передавать и данные сетки, и данные, касающиеся 
разбиения на страницы. В этом случае нет необходимости в усложнении конвей- 
ера МУС применением метода НЕп1 .ВепаекАсЕ1оп (). 


® Если визуализируемый графический элемент логически независим от контролле- 
ра, обрабатывающего запрос, возможно, контроллеру лучше не знать о нем и не 
передавать данные этому независимому графическому элементу (ответственность 
графического элемента является чуждой для контроллера). Например, при визуа- 
лизации глобального навигационного меню на странице АБоц! и$ (О нас}, контрол- 
лер АБочЕСопеко11ег не обязательно должен поставлять этому меню глобальные 
данные навигации. Все, что в действительности необходимо — это отобразить в 
определенном месте вывода меню навигации, не вдаваясь в детали реализации. 
Процесс отображения независимого графического элемента является исключи- 
тельно презентационным, подобно тому, как вывод изображения относится к 
обязанностям представления, а не контроллера. В сценариях подобного рода ме- 
тод НЕп1 .ВепдекАсЕ1опт() подходит как нельзя лучше, поскольку позволяет со- 
хранить разделение ответственности графического элемента и соответствующего 
контроллера. 
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Существуют также промежуточные случаи, когда графический элемент связан с 
предметной областью контроллера, но контроллер обычно не собирается предоставлять 
все данные, нужные графическому элементу. В таких случаях предпочтительнее реали- 
зовать графический элемент как частичное представление и передавать ему элементы 
У1емрака с помощью фильтра действия вместо встраивания этой логики непосредст- 
венно в каждый метод действия. Правильное структурирование кода — это настоящее 
искусство, основанное на квалификации и рассудительности. 


На заметку! В Вибу оп Вай$ существует понятие “компонентов”, которые играют аналогичную 
роль. Это пакеты, содержащие контроллер и представление, которые визуализируются в роди- 
тельском представлении с помощью метода Нибу под названием гкепдег сотропеп® (очень 
похожего на метод Нсп1 .ВепдекАсЕ1ог() из АЗРМЕТ МУС). Зачем об этом упоминать? 
А затем, что во многих случаях разработчики Вай$ считают компоненты противоречивыми и 
нежелательными, и эти мнения иногда распространяются на АЗРМЕТ МУС. Основная пробле- 
ма с компонентами Вай$ связана с тем, что их применение приводит к снижению производи- 
тельности. К счастью, при использовании АЗР. МЕТ МУС беспокоиться об этих проблемах не 
придется. Изначально задумывалось, что компоненты Вай$ должны допускать многократное 
использование в разных проектах. Замысел оказался неудачным, поскольку это препятство- 
вало каждому проекту иметь собственную инкапсулированную модель предметной области. Из 
всего сказанного разработчики веб-приложений АЗРМЕТ М\УС могут извлечь полезный урок: 
графические элементы, создаваемые с помощью НЕм1 .ВепаекАсетоп () , помогают разде- 
лять ответственность в одних проектах, и неприменимы в других. 


Создание графического элемента на основе 
метода НЕт1 .ВепаехАсЕ1топ 


Графический элемент, основанный на методе Нет1 .ВепехАсЕ1олт (), — это не что 
иное, как метод действия. причем любой. Например. можно создать класс контроллера 
Мог19С1ТоскКСопско11ег, содержащий действие Тпдех: 


ру611с с1азз ИотТАС]1оскСопего11ег : Сопего]1ег 
{ 
руб11с УлемВези1е Тпаех() { 
гегагп У1е\м (пем Р1се1опагу<зег1лпа, РабеТлите> { 
{ "ОТС", РабеТлме-ОесМом }, 
{ "Меи УогКк", Рафетлме. О сМом .АааНосг$ {-5) }, 
{ "Нога Копа", ВафеТ1лме. ОЕсМом.АааНоогз (8) } 
}); 


} 


Для этого действия можно добавить строго типизированное частичное представле- 
ние в /У1еиз /Иог1ЧС1осК/ Тпдех .азсх. Щелкните правой кнопкой мыши внутри мето- 
да действия и выберите в контекстном меню пункт АДа Ме\ (Добавить представление). 
В открывшемся окне отметьте флажок Сгеае а рага! мем/ {.азсх) (Создать частичное 
представление (.азсх)) и укажите 21сЕ1опагу<зЕх1па, РабеТлме> в качестве класса 
данных представления. Это частичное представление может содержать следующий код: 


<%@ Сорего1 Ъападоаде="с#" 
Тирег1Ез="Зузбем. Иер .Мус .Утем0зегСопето1<01сЕ1опагу<зЕг1па, Рафетипе>>" %> 
<ГаБ1е> 
<Бреаа><6Ег> 
<ЕН>Госа 1оп</ЕВ> 
<ЕВ>Таме</ЕН> 
</Е:></Ееаа> 
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<%$ ЕогеасВ (уаг ралфг 1п Моае1) { %> 
<Ег> 
<Е9><%= ра1г.Кеу %></Е9> 
<Е9><%= ралг.Уа1оае.ТоброгЕТ1теб$&г1па() %></649> 
</Ег> 
<% $> 
</каб1е> 


На заметку! Это частичное представление (т.е. шаблон АЗСХ). Использовать именно частичное 
представление для шаблона представления контроллера не обязательно — обычное представ- 
ление (АЗРХ) также будет работать. Тем не менее, имеет смысл использовать все-таки частич- 
ное представление, поскольку необходимо визуализировать только фрагмент НТМ!-разметки, 
а не страницу целиком. 


После всего этого действие Тпдех контроллера Иог19С1оскСопЕго11ег можно трак- 
товать как многократно используемый графический элемент, вызывая его из другого 
представления. Например, в каком-то другом представлении можно написать следую- 
ций код: 

<р3>Ношераде</63> 

<р>Не11о. Неге'$ а иог1А с1оск:</р> 

<% Нет1.ВепаегАсе1оп ("тпаех", "Мог1АС1осКк"}; %> 


На заметку! Обратите внимание, что синтаксис вызова Не] .Веп@егАсетоп () подобен Нм]. . 
ВепдегРаг®4.а1 ().. Метод не возвращает строку; он просто позволяет целевому действию пере- 
сылать вывод в поток ответа. Это полноценная строка кода, а не выражение, которое должно быть 
вычислено, поэтому не забывайте о точке с запятой, записывая <% ...; $>, ане <%= ... %>. 


Резульгирующий экран показан на рис. 10.6. 
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Рис. 10.6. Шаблон представления, который включает 
другое действие за счет вызова Н+и1 .ВепдегАсЕ1оп 


“За кулисами” НЕм1 .Веп4егАс®1оп() устанавливает новый объект Воиферака, со- 
держащий указанные значения сопЕго11ет и ас 1 оп, и использует его для запуска но- 
вого внутреннего запроса, начиная с вызова фабрики контроллеров. 

Фактически Неп1 .ВепдегАсе1от (} является оболочкой вокруг низкоуровневого ме- 
тода НЕш1 .ВепдегВоите () ‚, что позволяет передавать произвольную коллекцию данных 
маршрутизации, запускать внутренний запрос и отправлять вывод в поток ответа. 
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Методу действия можно также передать любые необходимые ему параметры либо 
в виде объекта ВоитеУ\а1иер1сЕ1опагу, либо как анонимно типизованный объект. 
Они направляются объекту Косферафа, который используется для внутреннего запро- 
са, а также привязываются к параметрам маршрутизации с помощью обычного меха- 
низма МУС ЕгатехогК. Для этого просто передайте третий параметр (под названием 
гоцееУа1иез), например: 


<% НЕм1 .ВепдегАселоп ("Траех", "Мог19С1Лоск", пем { у1з1огТлегопе = "СМТ" }); %> 


Внимание! Из-за деталей внутренней реализации встроенный фильтр [ОцЕроЕСасве] не со- 
вместим с методом НЕт1 .ВепаекАсЕ1оп (). Отнего ожидается кэширование вывода только 
из графического злемента, но на самом деле он всегда кэширует вывод для всего запроса. 
Чтобы устранить эту несовместимость, можно воспользоваться альтернативным фильтром кз- 
ширования вывода, находящимся по адресу ВЕЕр: //Е1пуцг1 . сом/мусОцериеСасве. Кроме 
того, структура Тептрра{а не доступна в качестве цели вызова НЕт1 .ВепдекАсЕзолп () (из-за 
особенностей ее загрузки и сохранения), но это редко является проблемой. Поскольку структу- 
ра ТептрраЕа должна использоваться только для сохранения данных во время перенаправлений 
НТТР 301 и НТТР 302, она не имеет отношения к независимому графическому элементу. 


Вызов метода НЕт1 .КепаегАсЕтоп<Т> с лямбда-выражением 


При желании можно воспользоваться обобщенной перегрузкой НЕ1 „.КепаегАсЛоп<Т> (). 
Как и НЕм1.АсЕ1оп<Т> (). она позволяет указывать целевой контроллер, метод дейст- 
вия и параметры с использованием лямбда-выражения. Например: 


<% Нёт1 .ВепдегАсЕ1оп<Мамезрасе.Мог1А9С1оскКСопего11ег> (х => х.Тааех()); % 


Значения, извлеченные из лямбда-выражения, поступают в объект Коц6ера{а и ис- 
пользуются для выполнения внутреннего запроса. 

Преимущество этой перегрузки в том, что она позволяет средству П\еШЗепзе оказы- 
вать помощь при выборе целевого метода действия и передаче ему параметров. Однако, 
подобно НЕп1 .АсЕтопЬ1оК<Т> (), она не может применяться для обращения к действи- 
ям, имена которых отличаются от имен методов, реализующих их на С# (т.е. действий. 
декорированных атрибутом [АсЕ1опМаце]). С обретением опыта, скорее всего, предпоч- 
тение будет отдаваться необобщенной перегрузке этого метода. 


Совместное использование компоновок 
страниц с помощью мастер-страниц 


Большинство веб-сайтов имеют набор общих интерфейсных элементов, таких как 
область заголовка и элементы управления навигацией. которые применяются на всех 
их страницах. В версии АЗРМЕТ 2.0 появилась возможность создавать один или более 
образцов компоновки, называемых мастер-страницами, и определять остальные стра- 
ницы сайта (“страницы содержимого”), заполняя пробелы на мастер-страницах. Во вре- 
мя выполнения то и другое комбинируется для генерации готовой НТМГ-страницы. Эта 
организация показана на рис. 10.7. 

Новую мастер-страницу создать легко: щелкните правой кнопкой мыши на папке в 
боаНоп Ехрогег и выберите в контекстном меню пункт АЧЧ=>Мем/ Нет (Добавить=>Новый 
элемент). В открывшемся окне укажите шаблон МУС \Ле\м/ Мазег Раде (Мастер-страница 
представления МУС). В соответствии с общепринятым соглашением, мастер-страницы, 
общие для всего сайта, помещаются в папку /У1еиз /5Ъагеа. Вообще говоря, их можно 
разместить где угодно, но затем на них придется ссылаться с указанием полного вирту- 
ального пути (включая расширения имен файлов). 
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(©) Ме. А! Пон гезегуед 


Мастер-страница 
Страницы содержимого 


Рис. 10.7. Базовая концепция мастер-страниц 


Мастер-страницы имеют расширение файла .Мазеег и выглядят как шаблоны 
представлений, за исключением того, что содержат специальные элементы управле- 
НИЯ <азр:СопеепЕР1асеНо14ек .../>, определяющие пробелы, которые должны быть 
впоследствии заполнены. Каждый раз, когда создается новая страница представления, 
ассоциированная с мастер-страницей, представление будет содержать элемент управ- 
ления <азр:Сопфеп® .../> для каждого пробела на мастер-странице. 

Если вы знакомы с мастер-страницами традиционной платформы АЗРМЕТ, то об- 
наружите, что мастер-страницы МУС и ассоциированные с ними страницы представ- 
лений работают именно так, как можно было ожидать. Пример установки и использо- 
вания мастер-страниц как части приложения Зройзоге уже приводился в главе 4. По 
этой причине, а также потому, что мастер-страницы на самом деле являются средством 
АЗРМЕТ \еБЕогтл$, а не АЗРМЕТ МУС, их детальное описание не приводится. 


Использование графических элементов 
на мастер-страницах представлений МУС 


Большинство разработчиков АЗРМЕТ МУС рано или поздно задаются вопросом: ка- 
ким образом размещать элементы управления или графические элементы на мастер- 
странице? Частичное представление можно легко визуализировать из мастер-страни- 
цы, используя <% Н{и1.ВепаегРаг®1а1 (); %>. Но как отправить некоторый объект 
Утемрафа частичному представлению? Для этого предусмотрено несколько способов. 


Способ 1: помещение единицы данных, специфичной для элемента 
управления, в структуру Утеирака с помощью контроллера 


Как уже должно быть известно, частичные представления по умолчанию имеют дос- 
туп ко всей структуре У1емрафа, переданной контроллером. Это верно и если частичное 
представление визуализируется из файла * .МазЕег вместо обычного шаблона пред- 
ставления. Поэтому, если контроллер заполняет \У1езРака ["уУа1аекокмуРаг%1а1"], 
то частичное представление может получить доступ к этому значению, независимо от 
того, визуализируется оно из мастер-страницы или из страницы содержимого. 
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Вместо отправки всей структуры У1езрафа в частичное представление можно пере- 
дать только специфическое значение, которое станет его объектом Моде1. Например. 
добавьте в файл .Мазсег следующую строку: 


<% НЕмф.ВепаегРаг&1а1 ("МуРагЕ1а1", У1емрафа ["уа1аегогМуРагЕ1а1"]}; %> 


Здесь нет ничего нового. Выше в этой главе уже было показано, как использовать 
вспомогательный метод НЕп1.ВепдегРак®1а1 (). 


Способ 2: помещение единицы данных, специфичной для элемента 
управления, в структуру УтеираЕа с помощью фильтра действия 


При наличии изрядного количества контроллеров и методов действий способ 1 стано- 
вится утомительным. Для каждого из них нужно помнить о необходимости заполнения 
\У1емрафа [ "уа1пегогМуРаг(1а1"], даже когда с ними ничего не планируется делать. 
Чтобы не смешивать несвязанные виды ответственности, лучше выделить эти функции. 

Взамен имеет смысл создать фильтр действия, который заполняет У1емрака|[ 
"уа1аекогМуРаг®1а1"]. Для примера создайте в любом месте вашего проекта АЗРМЕТ 
МУС класс, подобный показанному ниже: 


рую11с с1азз ОзезМумадесАек1риее : Асе1топЕ11ЕегАЕЕту1Ьове 
{ 
руЮ11с оуегг1ае уо1а ОпВези1еЕхеси{1п9 (ВезоЕхесиЕ1поСопеехЕ Е116егСопфех+®)} 
{ 
У1емВези1е у1емВезо1е = Е11ЕегСопфехе.Везо1е аз У1емВези1%; 
1Е (у1емВези1® != пи11) 
{ 
// Добавить значение в У1еирафа для будушей визуализации представления 
у1ечВезо1Е.\У1еираба ["уа1сегогМуРаг+1а1"] = зопеУа1ое; 


} 


} 

} 

Теперь необходимо просто пометить контроллер или метод действия атрибутом 
[ОзезМуй1аде\], и У1емраба ["уа1иегогМуРагЕ1а1"] будет заполнен соответствую- 
щим образом. так что шаблон „.Мазсек сможет извлечь это значение и передать его 
частичному представлению. 


На заметку! Многие разработчики Вайз предпочитают применять этот подход в качестве средства 
реализации многократно используемых элементов управления. Очевидно, что он в большей степе- 
ни соответствует чистой архитектуре МУ\С, чем вызов НЕм1 .ВепдегАсе1оп () (и его эквивален- 
та из Вай$), поскольку фаза сбора данных при подготовке контроллера происходит только один раз. 
Однако некоторое нарушение принципов М\УС иногда позволяет создать более аккуратную структу- 
ру приложения; именно поэтому все еще сохраняется место для НЕм1 .ВепдегкАсЕ1оп (). 


Способ 3: использование метода НЕш1 .КепдехгАсЕ1оп 


Способ 2 хорош, но следует помнить о необходимости связи контроллеров и дейст- 
вий со специфичным для графического элемента фильгром. Его удобно применять к 
каждому отдельному контроллеру, но это будет излишним при наличии в приложении 
представлений, которые вообще не визуализируют частичное представление. 

Простой и эффективной альтернативой способу 2 является метод Нл .ВепдегАсЕ1 оп (). 
Его легко использовать как в мастер-странице, так и в любом другом шаблоне представ- 
ления. В результате может быть получен графический элемент который умеет запол- 
нять свою структуру У1емрафа автоматически при каждой визуализации. Это особенно 
удобно в ситуациях, когда графический элемент должен работать независимо от всего 
остального на странице. 
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Реализация специального 
механизма представлений 


Подобно остальным компонентам МУС Егате\мо!{ К, механизм представлений Ме Коптз 
можно заменить любым другим механизмом представлений. Для этого можно реализо- 
вать собственный или адаптировать один из ряда механизмов представлений с откры- 
тым исходным кодом, каждый из которых имеет собственные достоинства и недостатки. 
Вскоре мы рассмотрим некоторые из наиболее популярных механизмов подобного рода. 

Механизм представления может быть как очень сложным (например, У’еБЕогпаз дос- 
таточно сложен), так и предельно простым. Он должен выполнять следующие функции. 


1. Принимать объект контекста тина У1еСопеехе, который включает информацию 
УтемВаба и другие объекты контекста, такие как Ведиез® и Везропзе. 


2. Использоваль эти объекты для отправки некоторого текста в поток ответа. 


Болышинство механизмов представлений предлагают определенного рода систему 
шаблонов, так что вторую функцию можно привести в соответствие с существующими 
потребностями. Вскоре вы убедитесь, что это несложно. 


Механизм представлений, визуализирующий 
ХМЕ-вывод с помощью Х$ЕТ 


Рассмотрим пример специального механизма представлений. Он должен обеспечить 
возможность записывать шаблоны представлений как ХГТ-трансформации и использо- 
вать их для визуализации любого документа, передаваемого в качестве \/1еиРафа.Моде]. 
Этот механизм может служить полной заменой стандартного механизма представлений 
М/еБЕогиаз, хотя с гораздо более скромными возможностями. 


Шаг 1: реализация интерфейса тугекЕпдатпе или наследование 
класса от УттЕна1РаЕЬРгоузаекУ1еиЕпоа1те 


Интерфейс ТУ1емЕпа1пе описывает возможность применения представлений (объ- 
ектов, реализующих Т\1ем). Это позволяет реализовать любую стратегию или соглаше- 
ния для конструирования или обнаружения представлений как на диске, так и в дру- 
гих местах, подобных базе данных. Если шаблоны представлений существуют в виде 
файлов на диске, то класс проще унаследовать от \/1кЕпа1РаенРгоу1аех\У1емЕпо1пе, 
поскольку в нем реализован поиск на диске в соответствии с соглашением об име- 
новании контроллеров и действий. От этого класса унаследован встроенный класс 
мебРогм\У1емЕпо1 пе. 

Ниже показан механизм представлений, осуществляющий поиск файлов ХТ 
({.х3з1%), которые хранятся в папке /У1еиз/имяКонтроллера или /\1енз/5тъагед. Этот 
класс можно разместить в любом месте проекта АЗРМЕТ МУС. 


руЮ11с с1азз Х5ШТУ1емЕпалте : У1гЕпа1Ра БРгоу1Аег\У1еиЕпа1ре 
{ 
раб11с хзрьтУлемЕпоалие () { 
УтеиТосаЕ1опРогмаез: = Рагё1а1У1емТосаЕ1опРогта®з = пем|[] { 
"- /М1еиз/ {1}/{0}.хэ®1е", 
"- /У1емз/5ВагеЯ/{0}.х51%", 


}; 
} 
ргобесфеЯ оуегт1ае тУ1ем СгеафеУ1ем (СопегоЛегСопфеехЕ сопего11егСопфехе, 
зЕг1па улемРабВ, зёг1па пазфетРа®В) { 


350 Часть И. АЗРМЕТ МУС во всех деталях 


// Этот механизм представления не поддерживает концепцию мастер-страниц, 
// поэтому игнорирует любые запросы на использование мастер-страницы 
тефаки пем Х5ЬТУтем (сопЕго11егСопфех®, у1емРаЪЪ); 


} 


ргофбесбеа оуегг1ае ТУ1ем СгеафеРагЕ1а1\У1ем ( 
Сопего11егСопеехЕ сопёго11егСопфехЕ, эег1па рагЕла1РаВ) { 

// Этому механизму представлений не нужно делать различия 
// между частичными и нормальными представлениями, поэтому 
// он просто вызывает метод Сгеабе\У1ем (} 
тегокп СгеабеуУ1ем (сопего11егСопеехе, рагЕ1а1ТРафВ, по11); 

} 

} 


Когда базовый класс 1 гЕпа1 Ра ПРгоУ1Чег\У1емЕпа1пе находит дисковый файл, со- 
ответствующий значениям в У1емТосае1опРогкца*$, он вызывает метод Сгеаке\1ем (} 
или СгеафеРагЕ1а1\У1ем() (в зависимости от того, что было запрошено). Теперь мы 
должны предоставить подходящую реализацию ТУтем. 


Шаг 2: реализация интерфейса ТУ1еи 


В данном случае механизм представлений предоставляет экземпляр Х5ГТ\У1ем (), оп- 
ределенный следующим образом: 


рур11с с1аз$ Х5ГТУ1ем : ТУлеч 
{ 
рг1уафе геадоп1у Хз1Сопр11еЧТгапзЕотм _фешр1асе; 


рур11с Х5ГТУ1ем (Сопего11егСопеехЕ сопего1егСопеехе, зЕг1па уфзенРаЕВ) 
{ 

// Загрузить шаблон представления 

_СешрТафе = пем Хз1Сопр11е@ТкапзЕогм (}; 

_фетрТафе . .оаЧ (сопего11егСопфех®.НЕЕрСопеехеь .Зегуег .МарРатн (у1емРае№)); 
} 


рир11с уо1а Вепдег (У1емСопфехе улемСопеехЕ, ТехЕИк1еег иг1фег) 
{ 
// Проверить правильность входящего объекта У1емрРафа 
ХРоситепе хи1Моде] = у1езСопеехь.У1емрафа.Моде1 аз Хросишеп+; 


ТЕ (хи1Моде] == пи11) 

Еёгом пем АгдопепеЕхсере1 ол ("У1емрРаба.Моде1 шазь ре ап ХРосимепе"} ; 
// Запустить трансформацию непосредственно в выходном потоке 
_Фешр1афе.ТгапзЕоги (хи] Моде] .СгтеакеВеадег(}, пи11, иг1 ег); 


} 
} 


Интерфейс Т\У1ем требует реализации лишь метода Вепаег (), который должен от- 
правлять вывод в поток ответа "г1{ег. В рассматриваемом примере это достигается 
выполнением трансформации на входящем объекте У1еирафа.Моае1. 


Совет. Обратите внимание, что АР!-интерфейс М\С Егатемогк предлагает осуществлять вывод 
путем записи в параметр типа ТехЕИг1 (еек. Это нормально, когда должен выводиться только 
текст, но что если создается механизм представлений, который выдает двоичные данные, та- 
кие как изображения или РОЕ-документы? В этом случае можно передавать необработанные 
байты в уземСопеехе .НЕЕрСопеехе. Везропзе .ОитриебЕгеам. 
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Шаг 3: использование созданного механизма представлений 


Имея перечисленные классы, можно вызывать специальный механизм представле- 
ний из метода действия. Ниже показан пример: 


рор11с с1азз ВоокзСоп+гко11ек : СопЕхо11ек 


{ 
рур11с У1еиВезо1% Тпаех () 


{ 
У1емВезо1 гези1е = У1ем (беЕВооК$ ()); 
ге501+.У1е\Епа1пеСо11есЕ1оп = век У1емЕпо1теСо11есЕ1оп { 
пеи ХЗТТУ1емЕпо1е () 
}; 
тебигп ге5о1*; 
} 


рг1уасе ХРосимеп® СефВоокз () 


{ 
хееоги ХРосомеп® .Рагзе (@" 
<Воокз> 
<Воок +141е='Ном Фо аппоу Ч9о1рЬ1п$' ап®рог='В. Зи1пиек'/> 
<Воок {141е='Ном Г зогу1уе ао1рЬ1п афасК' апеВог='В. Зиициег! /> 
</Воокз> 


"); 


} 


Как видите, в этом коде применяется необычный способ визуализации представле- 
ния: явное конструирование зкземиляра У1еиВези1е вместо простого вызова У1еи (). 
Это позволяет указать определенный механизм представления, который должен исполь- 
зоваться. Ниже будет показано, как зарегистрировать специальный механизм представ- 
лений в МУС Егатле\огК, чтобы избежать этого неудобства. 

Если сейчас запустить приложение, нажав <Е5>, и перейти по ОБТ, /ВооКз, отобра- 
зится экран с сообщением об ошибке, показанный на рис. 10.8. Очевидно, что причина 
возникновения оптибки в том, что еще не подготовлен шаблон представления. Обратите 
внимание, что сообщение об ошибке автоматически описывает соглашение об именова- 
нии, которое было установлено в подклассе У1хЕаа1РаБРгоу1 дех\У1емЕпа1 пе. 


|| Зегуег Еггог м '/’ Аррйсаноп. 


Тле май Тпдех' ог й5 таг соша поё Бе Гоипа. Те ойоилпа осаНопя 
уиеге зеаговед; 
—иИивизуВоок5/Ттпаах.х5 
</меилзиовагай/Ттаех. хз 


ге Слесувоп СТЕйе СТЕПЕ тес сезиезЕ Релзе геле: Не атас асе Рог иете. 
-в К огктатей зе 


ФезсмфНой: Ал опрар ЕС вхсерьор оссизтей 
$ зунытчаНов а62оЕ Не еггог асе си р 


ЕхсерНоп ОефаН в: 5} зетлув О регаопксерист. "Ба ес Таех огиз оазег сие гот ве ошпб Пе КУслИа Юсабога угеге зеагенеа о 


- 


Рис. 10.8. Сообщение об ошибке, которое отображается в ситуации, 
когда шаблон представления не удается найти на диске 
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Для решения этой проблемы создайте в файле /У1екз/воокз/Тиаех.хз1& транс- 
формацию ХЭГТ; содержащую следующий код: 


<?хи1 уегз10оп="1.0" епсоалта="оЕЕ-8"?> 
<х51:зСу1езбее® уег51оп="1.0" хш1п8:х81="ВЕСр: //миу. м3 .0ог9/1999/Х5Т/ТкапзЕогт" 
хит и8х81="игп: зсБешаз-п1скозоЕ&-сош:х516" ехс1е-гезо1&-рхеЕ1хез="изхз1" 
> 
<х31:оперое пеЕрод="Р{т1" 1идеп&="уез"/> 
<х51:Еетшр1аее паесв="/"> 
<р1>Му Еауог1ее Воокз</61> 


<о1> 
<х51:Еог-еасВь зе|1есс="Воокз/Воок"> 
<11> 
<Ь> 
<хз1:уа1ае-оЕ зе1ес&=" @&1Е1е"/> 
</ь> 
<х51:ехс> Бу </хз1:6ехе> 
<х51:уа1е-оЕ зе1ес*="васеВогк" /> 
</11> 
</хз1:Еог-еасёВ> 
</о1> 


</хз1:Еептр1а®е> 
</хз1:з$у1езрее > 


Теперь метод действия работает правильно (рис. 10.9). Получен полностью функцио- 
нальный специальный механизм представлений, поддерживающий шаблоны. 


1. Ноу ю ааноу дорыше 6х В. буйииег 


2 Ноу Езагсйтей дор анаск Бу В. Эклиниег 


| Му ЕауогНе ВооК$ 
| 


Рис. 10.9. Специальный механизм представлений в действии 


Шаг 4: регистрация специального механизма представлений 


Вместо того чтобы каждый раз явно указывать в контроллерах специальный 
механизм представлений, его можно зарегистрировать в статической коллекции 
\У1еиЕп91пе5.Епд1пез. Это должно быть сделано только один раз, обычно во время 
инициализации приложения. 

Добавьте следующий код в обработчик Арр11са 1оп 5%аг®() файла С1ора1.азах.сз: 


ргобесфеа уо14 Арр11са1оп Зах () 
{ 

Ве915$екВойиев (КообеТаБ1е.Коп®ез); 

У1емЕпа1тез .Епа1пез .Ааа (пех Х$ТТУ1еиЕпо1е ()); 
} 


Теперь предыдущее действие Тпаех контроллера ВооКзСопЕго11екг можно 
упростить: 
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рор11с УлемВезо1е Тпаех () 
{ 


гебоги У1ем (СеЕВооКз ()); 


} 


Коллекция У1емЕпо1пез .Епо1пез по умолчанию содержит зкземнляр Иебгохи\1емеполне. 
Поэтому МУС ЕгатеуогК сначала будет запраптивать у ИеБРоги\1е"Епа1пе представле- 
ние. Если соответствующий файл .азрх или .азсх не будет найден, представление за- 
прашивается у Х5ТТ\У1емЕпа1 пе. Этот механизм позволяет использовать сразу несколько 
механизмов представлений параллельно, с установкой для них определенных приорите- 
тов. Для каждого запроса будет выбираться первый механизм представления, который 
в состоянии найти шаблон, соответствующий его соглашению об именовании. 

Для назначения специальному механизму представления приоритета, превышаю- 
щего приоритет встроенного ИеьЕРогм\У1еиЕпда1пе, измените код инициализации в 
С1оЬа1.азах.сз следующим образом: 


ргосесфкеа у014 Арр11са®1оп З%агЕ() 
{ 
Вед15техВосеез (ВоибеТа1е.Воп+ез); 
У1емЕпо1пез .Епа1пе$ .С1еак(); 
УземЕпа1пе5 .Епа1пез.Ада (пеи Х5ГТУЗемЕпо1те ()); // Первый приоритет 
УлемЕпа1тез .Епд1пез.Ааа (пем МеБЕогиУ1еиЕпоа1е ()); // Второй приоритет 
} 


Разумеется, если механизм МерЕоги\У1е Епа1юе не должен использоваться, его нуж- 
но просто не включать в У1еиЕпа1птез .Епа1пез. 


Использование альтернативных 
механизмов представлений 


Несмотря на то что АЗРМЕТ МУС является относительно новой платформой, для нее 
существует ряд заслуживающих внимания механизмов представлений. Болыцинство 
из них — это механизмы представлений, перенесенные из других платформ веб-раз- 
работки на основе модели МУС, каждый из которых обладает своими сильными сторо- 
нами. Следует отмегить, что лишь немногие из них достаточно хорошо интегрированы 
в \15ща| Эбаа, как механизм представлений Ме ЕРогилз по умолчанию (на момент на- 
писания книги только механизм ЗратК поддерживался средством Пе 5еп$е), однако 
некоторые разработчики АЗРМЕТ МУС все равно сочтут их легкими в использовании. 

В оставшейся части этой главы вы найдете краткое руководство по использова- 
нию каждого из следующих механизмов представлений с открытым исходным кодом в 
АЗРМЕТ МУС: 


®е МУаосцу 

® Вгай 

®е Эра 

® МНап 

Для подробного описания каждого из зтих альгернативных механизмов представле- 
ний (их установки, правил и синтаксиса, специальных средств. особенностей и проблем) 
в книге места нет, к тому же некоторые детали наверняка изменятся к моменту, когда 
вы прочитаете о них. Поэтому ниже излагаются только основные идеи, положенные в 


основу каждого их этих механизмов, и приводятся характерные примеры синтаксиса. 
Дополнительные сведения можно получить на веб-сайтах соответствующих проектов с 
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открытым кодом. Там же можно найти последние версии для загрузки и установки, а 
также примечания касательно использования. 

Во всех приведенных далее примерах предпринимается попытка сгенерировать один 
и тот же вывод на основе следующей общей структуры У1еираса: 


\У1еирафа ["пеззадче"] = "Не11о, иог1а!"; 
У1теиРафса.Моае1 = пеи 156<Моппфа1т> // Моспфа1т просто содержит три свойства 


{ 


пеи Мопспфа1п { Маме = "Еуегез®", Не1аВ*=8848, 
Рафер1зсоуегеЯ = пеи РавеТ1ме (1732, 10, 3) }, 
пем Моппфа1т { Маше = "К111пап)аго", Не196%=5895, 
Рафер1зсоуегеа = пем РафеТаие (1995, 3, 1) }, 
пеи Моопфалп { Маше = "бпомаоп", Не196=1085, 


Рафер1зсоуегеа = пем рафеТлше (1661, 4, 15) }, 
}; 


Использование механизма представлений М№УМеюосну 


АрасБе УеюосНу — зто универсальный механизм шаблонов на основе Зауа, который 
может использоваться для генерации почти любого текстового вывода. Его перенесен- 
ная в среду .МЕТ версия под названием Муеюсйу усиливает стандартный механизм пред- 
ставлений СазЙе МопоКай, являющийся альгернативой платформе разработки веб-при- 
ложений .МЕТ МУС. Если вы знакомы с синтаксисом М\юсЦу, то вам наверняка будет 
интересно его использовать в среде АЗРМЕТ МУС. Это довольно легко, потому что в со- 
став проекта МУС СопН 1 входит класс МусСопег1Ъ .Саз1е.МУе1ос1 6 уУ1еиРГасфоку — 
механизм представлений, усиленный средствами МУ@юосЦу. Проект МУС СопЕёЪ дос- 
тупен для загрузки по адресу ими. содер1ех .соп/муссоп®т1ю. Приведенные далее 
инструкции относятся к версии 0.0.1.222 этого проекта°. 

Шаблоны МУ&юосНу имеют расптирение имен файлов .\хла, поэтому шаблон по умол- 
чанию для действия Типдех контроллера НопеСореЕго11ет находится в /У1еиз/Нопе 
Тпдех .ум. Рассмотрим пример шаблона МУ&осНу: 


<62>$теззаае</62> 
<р>Неге'з зоше Чдафа</р> 
#{ЕогеасВ ($т 1п $5У1емПафа.Модет) 


#БеЁогеа11 
<фаБ1е итаЕр="50%$" рогаег="1"> 
<Етеаа> 
<Еи> 
<Еп>Мапе</&В> 


<Ер>Не1аВ® (т) </ЕВ> 
<ЕВ>рафе 91зсоуегед</ ЕВ» 
</Ех> 
</{Веаа> 
#еась 
<Еи> 
<Еа9>5щ.Маше</Еа> 
<Еа>5м.Незав&</Еа> 
<Е9>6т.Басер1зсоуеге@. Тоброг®Рафебхг1пча () </Еа> 
</Ег> 
#аЕега11 
</фаб1е> 
#епа 


6 На момент выхода русскоязычного издания этой книги текущей стабильной версией МУС 
СопЫ была 1.0.0.987, а кандидатом на выпуск — версия 2.0.34.0 для МУС2 КС. 
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<Еоги асе1оп="50у1 .АсЕТоп ("Зиби1ЕЕта11")" пеероа="розе"> 
Е-па11: $5НемТ.ТехеВох ("ема11") 
<1приЕ фуре="зи6т1" уа1ае="бо6зск1ре" /> 

</Еоги> 


Для описанной ранее структуры У1еРаёа это визуализирует экран, показанный на 
рис. 10.10. 
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Рис. 10.10. Вывод, полученный с использованием механизма представлений ММеосйу 


М\еюсцу поддерживает удобный синтаксис #ЕокеасЪ, который позволяет указывать 
текст, подлежащий выводу перед каждым элементом (#6еотееас|), между элементами 
(=реЕмееп)}, после всех элементов (#аЁеега11), а также, когда в наборе нег элементов 
(=подака). Он действует как язык с утиной типизацией (т.е. неявной динамической ти- 
пизацией (Чиск-буред)), позволяющей обращаться к свойствам объектов по имени (на- 
пример, $ .Не1аь+), не зная типа объекта: это значит, что предварительно выполнять 
приведение объекта к известному типу не придется. 

Однако М\УеюсЦу не позволяет вычислять произвольные выражения С#: можно вычис- 
лять только тевыражения, которые вписываются в его серьезно ограниченный синтаксис. 
На момент написания книги механизм №Уеюсйну было трудно использовать для вызова 
встроенных вспомогательных методов МУС Егатле\могКк. Вдобавок, из-за универсальности 
в синтаксисе не предусмотрено какой-либо оптимизации при генерации НТМГ-разметки, 
в отличие от ряда других механизмов. которые рассматриваются далее. 

В механизме М\аюосйу имеется система “компоновок” и “компонентов”, которые за- 
меняют мастер-страницы и пользовательские элементы управления \/еЕогтиз. 


Использование механизма представлений Вгай 


Механизм Вгай был создан для СазЙе МопоВай как альгернатива МУаюсцу. Его ос- 
новное отличие связано с использованием язык Воо” для встроенного кода и выраже- 
ний, а это значит, что он, подобно шаблонам АЗРХ, но в отличие от шаблонов МУЕюсйу, 
допускает произвольные выражения и фрагменты кода. Для применения Вгай в сре- 
де АЗРМЕТ МУС достаточно воспользоваться классом МусСопет1Ь .\У1енЕасбог+ез. 
Зха11\У1еиЕасбогу из проекта МУС СопёЧЪ. Опять-таки, приведенные ниже инструк- 
ции касаются версии 0.0.1.222 этого проекта. 


7 Воо — зто статически типизированный язык программирования на основе .МЕТ с синтак- 
сисом, подобным Рупоп. Его основные достоинства — лаконичный синтаксис и исключи- 
тельная гибкость. 
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Шаблоны ВгаЙ имеют расппирение .Ьга11, поэтому представление по умолчанию 
для действия Тпаех контроллера НомеСопетго11ет будет находиться в /У1еиз/Ноте/ 
Тпдех.рга11. Рассмотрим пример: 


<р2>5{пеззаде}</62> 
<р>Неге'з зоще Чафа:</р> 
<Еаб1е илаер="50%" рогаег="1"> 
<ЕРеаа> 
<Еу> 

<ЕБ>Мапе</Ев> 

<ЕП>Нелаве (т) </Ев> 

<ЕБ>РаЕе 91зсоуекед</ЕЬ> 


</сх> 

</ЕВеаа> 

<% Еог ш ап Улемрафа.Мо@е1: %> 
<Ех> 


<Е4>5 (ш.Маме } </&а> 
<Еа>$ {ш.Нетаве}</е9> 
<Е9>5 {и.Рафсер1зсоуегеа.ТоЗрогЕрафеб$г1пча () }</6а> 
«уЕи> 
<% епа %> 
</фаб1е> 
<Еоги ас®1о0п="$ {Ог1.Асстоп ("51 ЕЕма11") }" шебвод="розе"> 
Е-па11: ${В6т1.ТехеВох ("ета11") } 
<1праЕ суре="зоби1е" уа1е="бибзст1Ье" /> 
</Еоги> 


Этот шаблон представления дает точно такой же экран. как показанный на рис. 10.10 
ранее в главе. 

Как видите, механизм Вга! очень похож на МУ@осйу. Он не поддерживает синтаксис 
#Еогтеасв, но существенно облегчает вычисление произвольных выражений. Вгай так- 
же имеет систему “компоновок” и “компонентов”, которые заменяют мастер-страницы 
и пользовательские элементы управления У’еБЕогтт$. 


Использование механизма представлений ЗрагК 


брагк — зто механизм представлений для АЗРМЕТ МУС и СазНе МопоВай. Он досту- 
пен для загрузки по адресу БЕЕр://аеу.Яе]ага1т.ога/. Назначение ЗраК состоит в 
интеграции выражений встроенного кода в поток НТМГ-разметки. Это минимизирует 
переключения контекста между кодом и НТМГ-разметкой и обеспечит больший комфорт 
веб-дизайнерам при работе с шаблонами представлений. Вдобавок механизм ЗрагК по- 
зволяет использовать произвольный код С# для вычисления выражений. 

Шаблоны ЗрагК имеют раснтирение „.зрагк, так что шаблон по умолчанию для дейст- 
вия Гпдех контроллера НоцеСопго11ег будет находится в /У1еиз/Ноще/Тпадех . зрагК. 
Рассмотрим пример, основанный на ЗрагК версии 1.0.317.08, который визуализирует 
тот же экран, что был показан ранее на рис. 10.10: 


<изе пацезрасе="Зузеет.Со11ес®1опз .Сепег1с"/> 

<изе пашезрасе="бузвен.Мер.Мус.НЕш1"/> 

<у1емааеа поае1="ТТ,1 3% [ [ПространствоИмен.Мопп®а1т]]"/> 
< 2>5$ {Улеирака ["шеззаде"] }</62> 

<р>Неке'$ зоше дафа</р> 

<фаб1е итаЬ="50%" рогаег="1"> 


8 На момент выхода русскоязычного издания этой книги текущей стабильной версией Зрагк 
была 1.0.39917 ВС2. 
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<Ереаа> 
<> 
<ЕБ>Мапше</ ЕВ» 
<ЕБ>Не1оВЕ (м) </еЬ> 
<ЕР>Рафе а1зсоуегеа</еЮ> 
</Ег> 
</сБеад> 
<Ег еасв='уаг м 11 Моде1'> 
<Еа>5 {и.Мате}</Еа> 
<Еа>$ {и.Незаве}</е9> 
<Е9>5 {ш.Рафер1зсоуеге@.То5ЗвогеРафке5г1па () }</а> 
«уек> 
</Еаф1е> 
<Гогм асе1оп="$ {0 г1.АсЕТоп ("боб ЕЕта11") }" пеерод="роз®"> 
Е-па11: ${Нет1.ТехЕВох ("еща11") } 
<1приЕ суре="зи6т1е" уа1ще="борзск1Ье" /> 
</Еоги> 


Полужирным выделена наиболее интересная строка. Как видите, здесь нет явно- 
го цикла Гогеасв, а нотация итераций элегантно сокращена до атрибута дескрин- 
тора. ЭрагК также предлагает весьма аккуратный способ включения внешних час- 
тичных шаблонов за счет простой ссылки на них в виде дескрипторов (например, 
<МуРагЕ1а1Тетр1афе пурагап="уа1"/>) даже без необходимости какой-либо регистра- 
ции этих специальных дескрииторов. И, наконец, ЗратК также поставляется с системой 
мастер-игаблонов, которые работают подобно мастер-страницам УМеБЕогиив. 

Обратите внимание, что поскольку механизм ЗратК основан на С#, он не ведет 
себя как язык с утиной типизацией. Чтобы обратиться к свойствам объекта, снача- 
ла необходимо привести этот объект к определенному типу, при необходимости им- 
портируя его пространство имен. Вот почему в начале шаблона присутствуют узлы 
<изе памезрасе="..."/>. 


Использование механизма представления МНат! 


Самое интересное припасено на десерт! МНат| — это перенесенная версия меха- 
низма представлений Нап для КиБу оп Кайз, в котором для генерации НТМГ-разметки 
применяется совершенно другой подход. 

Все механизмы представлений, которые вы видели до сих пор, по сути, являются 
системами для включения кода в файл НТМГ. Однако МНапИ — это скорее язык, ори- 
ентированный на предметную область (251), для генерации ХНТМЕ.. Его файлы шабло- 
нов содержат минимальное описание ХНТМЕ и в действительности совсем не похожи 
на ХНТМГ-разметку. Механизм представлений МНап доступен для загрузки по адресу 
соде .доод1е.сом/р/пБаш1 /. 

Его шаблоны имеют расширение .паш1, так что шаблон по умолчанию для дейст- 
вия Тидех контроллера НопеСопего11ек будет находиться в /У1еиз/Номе/Тпаех.Ваш1. 
Рассмотрим пример, который визуализирует тот же экран, что был приведен ранее на 
рис. 10.10: 


$62= У1емраба ["меззаде"] 
$р Неге'5 зоме дафа 
$фаб1е{ и1аЕЬ="50%", рогдег=1 } 


$ЕПеаа 
$Ек 
$ЕР Маме 


ФЕВ Незарве (м) 
$ЕБВ Рафе а1зсоуекея 
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— ЕогеасВ (уахг ш 1п Моае1) 
$Е к 

%$Е4= ш.Мапе 

$Еа= ш.Нелаве 

%Еа= ш.Рафер1зсоуегеа. ТоброгЕРа®еЗЕг1пча () 

$Еогш{ ас®1оп=0г1.Асетоп ("ЗбиоБи1еЕта11"), пшеброд="розе" } 

Ета11: 
= Ни] .ТехёВох ("ета11") 
$1проЕ { Еуре="зо6т1", уа1ое="5о6зск1ре" } 


Что это вообще такое? Каждая строка предварена символом %, обозначающим де- 
скринтор. Атрибуты помещаются в фигурные скобки ({...}). Отступами задается ие- 
рархия дескрипторов. Для вычисления произвольных выражений С#, включая вызов 
вспомогательных методов НТМГ, применяется операция =. Строки, начинающиеся со 
знака дефиса (-) представляют операторы С#. Несмотря на то что МНап основан на С#, 
он выглядит как язык с утиной типизацией, позволяя обращаться к свойствам объек- 
тов без приведения типов. В МНап также имеется система“компоновок” и “разделов”, 
заменяющих мастер-страницы и пользовательские злементы управления \еЪЕогипз$. 
Несмотря на непривычный синтаксис, МНап! предлагает очень сжатый и точный спо- 
соб описания динамической ХНТМ!-разметки. 

Из всех перечисленных механизмов представлений МНап наиболее труден в освое- 
нии, особенно учитывая определенную нехватку документации (хотя этот проект на- 
верняка будет растпиряться). Нап стал довольно популярным в мире Кайз, и МНап\, 
похоже, также завоюет массу сторонников в мире АЗРМЕТ МУС. 


Резюме 


Благодаря этой главе, вы увеличили свой багаж знаний о стандартном механиз- 
ме представлений АЗРМЕТ МУС, известном под названием механизма представлений 
У’еЬЕогиаз. Вы узнали о каждом из доступных способов включения динамического со- 
держимого в шаблон представления, и научились работать с многократно используе- 
мыми графическими элементами и мастер-страницами. Вы также видели, как файлы 
АЗРХ транслируются в классы МЕТ на веб-сервере. В завершение вы ознакомились с 
некоторыми наиболее известными альтернативными механизмами представлений. 

Теперь вы должны хорошо разбираться в маршрутизации, контроллерах, действиях 
и представлениях. В следующей главе будут рассмотрены наиболее распространенные 
задачи, возникающие во время веб-разработки, включая ввод и проверку достоверно- 
сти данных, поскольку на первый взгляд их решение далеко не очевидно. Остальные 
главы книги посвящены таким связанным вопросам, как технология Адах, безопасность. 
развертывание и эффективное применение других средств, предлагаемых расширенной 
базовой платформой АЗРМЕТ. 


ГЛАВА 11 


Ввод данных 


омимо перемещения по страницам и просмотра их содержимого, болыпинство 

веб-приложений предоставляет пользователям возможность вводить и редакти- 
ровать данные. Существует бесчисленное множество способов построения и настройки 
пользовательского интерфейса ввода данных, с помощью которых можно добиться оп- 
тимального восприятия содержимого конечными пользователями. 

Платформа АЗРМЕТ МУС спроектирована с упором на простоту и гибкость. Она 
предлагает эффективные, аккуратные, тестируемые строительные блоки, с помощью 
которых можно создавать практически любое веб-приложение, не используя жестко за- 
данные элементы управления. Например. вместо готового элемента типа мастера МУС 
Егате\могК предоставляет широчайшие возможности по конструированию любого рабо- 
чего потока операций за счет комбинирования нескольких шаблонов представлений и 
вызовов мегода Веа1гкесеТодАСЕЗ оп (). 

Имея в распоряжении такую гибкость, не всегда удается сразу определиться, с чего 
начать. Процесс разработки в АЗРМЕТ МУС не столь очевиден, как в АЗРМЕТ Ме БЕогиаз, 
потому что нет визуального редактора, поддерживающего технологию перетаскивания. 
Но по мере возрастания сложности требований к проекту простота и надежность про- 
ектирования кода МУС начинает приносить дивиденды. 

Первая часть главы посвящена привязке модели — мощному средству МУС Егатемюгк 
для обработки ввода данных, основанной на соглашениях вместо написания болышого объ- 
ема кода. После этого будет показано, как применить имеющиеся знания о контроллерах, 
представлениях, привязке модели и архитектуре МУС для решения следующих задач. 


® Обеспечение соблюдения правил проверки достоверности и бизнес-правил. 


® Сохранение состояния пользовательского интерфейса между множеством 
запросов. 


® Создание многошаговых форм (также называемых мастерамц). 
® Блокирование спама с использованием графического элемента САРТСНА. 
® Предотвращение подделки данных с использованием кодов НМАС. 


Перечисленные задачи служат липть начальными точками; их всегда можно привес- 
ти к конкретным нуждам. 


Привязка модели 


Каждый раз, когда посетители сайта отправляют НТМТ.-форму, приложение посы- 
лает НТТР-запрос, содержащий данные формы в виде набора пар “ключ/значение”. 
Каждый необходимый элемент данных можно выбирать вручную (например, извлекая 
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Весоезс . Гоги ["рвопемипег" ]}, но это трудоемкий процесс, особенно если метод дей- 
ствия должен принимать множество элементов данных и использовать их для конст- 
руирования или обновления объекта модели. 

Привязка модели — это механизм АЗРМЕТ для отображения данных НТТР-запроса 
непосредственно на параметры метода действия и специальные объекты „МЕТ (включая 
коллекции). Как и можно было ожидать, в АЗРМЕТ МУС определен ряд соглашений об 
именовании, которые позволяют быстро отображать сложные структуры данных без не- 
обходимости специфицировать вручную все правила такого отображения. 


Привязка модели к параметрам метода действия 


Ранее средство привязки данных модели применялось каждый раз, когда методы 
действия принимали параметры. Например: 


руЮ11с АсЕ1опВези1Е Вед1зеегМепфет (511149 етма11, РабеТуме дафеоЕВакеЬ) 
{ 

У Знть 
} 


Чтобы выполнить этот мегод действия, встроенный объект Сор то11екАс®1опТиуоКег 
платформы МУС ЕгатехмогК использует компоненты по имени реРаи1ЕМоде1Вапаег и 
Уа1чеРго\1Аегр1 с 1опакгу (если только вы не замените их специальными реализациями 
соответствующих интерфейсов) для преобразования данных входящего запроса в соот- 
ветствующий объект .МЕТ для каждого параметра метода действия. Функционирование 
этих компонентов рассматривается далее в главе. 

Компонент Уа1аеРхо\19егр1сЕ1опаку отвечает за поставку неформатированных 
данных. передаваемых в запросе НТТР. Он извлекает значения из мест, перечисленных 
в табл. 11.1, причем в указанном порядке приоритетов. 


Таблица 11.1. Места, из которых механизм привязки модели по умолчанию извлекает 
свои неформатированные входные данные (в порядке приоритетов) 


Место Интерпретация 
Роги (те. параметры РОЗТ) С учетом культуры (Сы1когеТа Ро .СоггепеСо1иге) 
ВБоиеерака (т.е. параметры мар- Без учета культуры (Со1СокеТпо .Тпуах1апеСо1оге) 


шрутизации в фигурных скобках 
плюс параметры по умолчанию) 


ОпекуЕт1п9 Без учета культуры (Си1ЕотхеТио . Тпуах1апЕСи1еике) 


Таким образом, параметр ета11 из предыдущего примера будет заполняться из сле- 
дующих мест. 


1. Ведиез® .Гоги["ета11"], если существует. 

2. В противном случае Воцеерафа .\а1щез ["еща11"], если существует: 

3. В противном случае Кедиез® .Опегу$Ет1поа ["еща11"], если существует 
4. В противном случае по11. 

То же самое верно и для параметра ЗасеОоВакеВ, но с двумя отличиями. 


® Значением Басет1ие не может быть по11, поэтому, если в трех первых из 
перечисленных выше мест значение не найдено, генерируется исключение 
Тпуа11ЗОрега(1опЕхсере1ол со следующим сообщением Тве рагащефегз 91с- 
$1опакгу сопфта1пз а по11 епёку Еог рагамееег 'ааъеоЕВ1еЕВ' оЁ поппи11аБ1е 
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туре 'бузеет.РафеТ1ме' (Словарь параметров содержит элемент по11 для пара- 
метра дас еотВ1гЕВ типа буз®ем.РафеТ1ме, не допускающего значение по11). 


® Если даееоЕВ1геЕВ заполняется из ОНТ, запроса (места 2 и 3), то этот параметр 
помечается для нечувствительной к кульгуре интерпретации, поэтому для него 
должен использоваться универсальный формат даты гггг-мм-дд. Если же он 
заполняется из данных РОЗТ (место 1), то должен быть помечен как чувстви- 
тельный к кульгуре, что приводит к различным интерпретациям в зависимости 
от настроек сервера. Поток в режиме культуры ОЗ должен принимать формат 
даты мм-дд-гггг, в то время как поток в режиме кульгуры ВО ожидается формат 
дл-мм-гггг (но оба они нормально работают с форматом гггг-мм-дд)". Причина 
такого отличия в поведении состоит в том, что введенные пользователем данные 
имеет смысл интерпретировать как чувствительные к культуре, и поля форм час- 
то используются для приема такого рода пользовательских данных. Однако по 
определению строка запроса и параметры марптрутизации в ОВ! не должны со- 
держать специфичное для культуры форматирование. 


Как только поставщик значений Уа]лерРго\1Аехрлсе1опагу обнаруживает подходя- 
щие строки в данных входящего запроса, компонент РеЁаи1{Моде1В1паег преобразует 
их в произвольные объекты .МЕТ. Для работы с простыми типами, подобными 116 и 
РасеТ1ше, он использует средство Туре Сопуецмет, встроенное в .МЕТ. Однако для ма- 
нипулирования коллекциями и пользовательскими типами понадобится что-то более 
сложное. 


Привязка модели к специальным типам 


Некоторые методы действий можно значительно упростить, передавая им парамет- 
ры специальных типов вместо создания и заполнения экземпляров вручную. Взгляните 
на следующее представление, которое визуализирует простую форму регистрации 
пользователя: 


<$% из1па (НЕ .ВедлоЕоги("Вес1з6ехМепЬет", "Ноше")) { %> 
<Я1у>Маме: <%= Неи1 .ТехЕВох ("тмурегзоп.Мате") %></а1х> 
<Ч1у>Ета11 аа@хезз;: <%= Нем1.ТехфВох ("турегзоп.Ета11") %$></а91у> 
<Ч1у>Вафе оЕ Б1уЕП: <%= НЕм1.ТехеВох ("пурегзоп.ВаееоЕВакЕВ") %$></91у> 
<1приЕ Еуре="забиле" /> 

<% } %> 


Эта форма может отправить данные следующему методу действия, который вообще 
не использует привязку модели: 


руБ11с АсЕ1опВезо1Е Вед1звехМепфех () 
{ 
уаг турегзоп = пем Регзоп(); 
пурегзоп .Маше = Весаез® ["турегзоп.Мапте"]; 
пурегзоп.Ета11 = Весаез® ["турегзоп.Ета11"]; 
пурегзоп.ПасеоЕВ1туЕН = РафеТ1ще.Рагзе (ВКесоез® ["пурехгзоп .рафеоЕВакЕЮ"]); 
// -... какие-то действия с пурегзоп 


1 Потоки АЗРМЕТ по умолчанию устанавливают режим кульгуры сервера. но это мож- 
но изменить, присвоив соответствующее значение свойству Тогеа@.СиггепеТЬтеаа . 
СиггепеСи1еоге или добавив узел типа <91ора11хаЕ1оп со1еохе="ка-ВО" /> внутрь узла 
<зузЕет.мер> в файле иеь.сопЕ1а. Более подробную информацию об этом, а также об ав- 
томатическом обнаружении предпочитаемых настроек культуры для каждого посетителя, 
можно найти в главе 15. 
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Избавиться от рутинного кода можно так: 


руБ11с АсЕлопВези1е Веч1зЕехМепоег (Регзоп турегзоп) 
{ 
// ... какие-то действия с пурегзоп 


} 


Когда у РеРаз1ЕМоде1В1п9дег запрашивается передача объекта некоторого специаль- 
ного типа .МЕТ вместо простого примитивного типа вроде зег1па или 11%, он с помо- 
щью рефлексии определяет общедоступные свойства, имеющиеся у специального типа. 
Затем он вызывает себя рекурсивно для получения значения каждого свойства. Эта ре- 
курсия позволяет заполнить весь граф пользовательского объекта за один проход. 

Обратите внимание на соглашение об именовании, используемое при сопостав- 
лении злементов запроса со свойствами объекта: по умолчанию производится поиск 
значений имяПараметра. имяСвойства (например, мурегзоп .Ета11). Это гарантирует 
возможность присваивания входных данных корректному объекту-параметру. По мере 
продолжения рекурсии средство привязки ищет значения имяПараметра.имяСвойст- 
ва.имяПодсвойства и тд. 


На заметку! Когда компонент БеЕац1{Моде1В1пдет должен создать экземпляр специально- 
го типа объекта {например, Регзоп в предыдущем примере), он использует метод .МЕТ под 
названием АсЕ1уафох .СгеафеТизтапсе () , который полагается на наличие у этих типов 
общедоступных конструкторов без параметров. Если ваши типы не имеют конструкторов без 
параметров, или необходимо создавать их экземпляры с применением контейнера 10С, мо- 
жете унаследовать подкласс от БеЕаз1ЕМоае1В1паех, переопределив его виртуальный ме- 
Тод СкеаееМоае1 () , а затем присвоив экземпляр специального средства привязки свойству 
МоЧе1В4паегз .Влпдетз .РеЕал1ЕВзпаекг. В качестве альтернативы можно реализовать 
специальное средство привязки только для данного специфического типа. Пример специаль- 
ного средства привязки будет приведен ниже. 


Теперь давайте рассмотрим некоторые способы настройки алгоритма привязки. 


Указание специального префикса 


В предыдущем примере предполагается, что средство привязки по умолчанию за- 
полнит параметр пурегзоп, запрашивая у поставщика значения пурегзоп . Мане, 
пурегзоп .Ета11 и пурегзоп .РафеоЕВ1кЕВ, которые обнаруживаются в местах, пере- 
численных в табл. 11.1. Несложно догадаться, что префикс птурегзоп определяется по 
имени параметра метода действия. 

При желании можно указать альгернативный префикс, используя для этого атрибут 
[8104]. Например: 


РУБЫс АсЕ1опВезо1 Вед1зтехМетьек ( [В1па (РгеЕ1х = "пемазег")] Регзоп тпурегзоп) 
{ 

Дал 
} 


Теперь у поставщика значения будут запрошены пемизег Мане, пемизег.Епа11 и 
пеиизег. РасеоЕВлтгЕ |. Такая возможность в основном удобна, если вы не хотите, что- 
бы имена НТМГ-элементов ограничивались именами соответствующих параметров ме- 
тода С#. 


Пропуск префикса 


При желании префиксы можно вообще не использовать. Это значит, что разметку 
представления можно упростить: 
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<% 15119 (НЕ .ВедлпЕогм("ВедузехМепьет", "Ноше")) { %> 
<Я1\у>Маме: <%= Ней .ТехеВох ("Маме") %></а1у> 
<Я1\у>Ета11 аЯЯгезз: <%= Н&и1 .ТехеВох ("Ета11") $%></91х> 
<а1у>Раее оЁ Б1уЕП: <%= Нем1 .ТехЕВох ("РафеоЕВагеВ") $></а1у> 
<1прие Еуре="забиее" /> 

<$% } > 


Обратите внимание, что элемент управления для ввода адреса электронной почты 
теперь называется просто Ета11, а не пурегзоп .Ета11 (то же касается и других элемен- 
тов ввода). Входные значения успепно привяжутся к методу действия, определенному 
следующим образом: 


рУБ11с АсЕ1опВези1е Вед1зЕехМепьет (Регзоп шурегзоп) 


Такой код по-прежнему работает, потому что БеЕаи1ЕМоде1В1паег сначала ищет 
значения с префиксами, выведенными из имени параметра метода (или из любого ат- 
рибута [В1па], если таковой имеется). В рассматриваемом примере это значит, что 
он будет искать входные пары “имя/значение”, ключи которых снабжены префиксом 
турегзоп. Если такие входные значения не будут найдены, а в данном примере так и 
случится, он вновь попытается найти входные значения, но на этот раз не используя 
префикса вообще. 


Выбор подмножества свойств для привязки 


Предположим, что класс Регзоп, применяемый в последних нескольких примерах, 
имеет свойство типа Боо1 по имени ТзАат1п, которое необходимо защитить нежела- 
тельного воздействия извне. Если метод действия использует привязку модели для 
получения параметра типа Регзоп, то злоумышленник может просто присоединить 
фрагмент ?Т5Ади1п=екие к ОВГ, используемому при отправке формы регистрации 
членства, и это значение свойства благополучно будет применено к вновь созданному 
объекту Регзоп. 

Ясно, что такую ситуацию нельзя считать приемлемой. Помимо безопасности суще- 
ствует и ряд других причин, по которым понадобится явно контролировать подмножест- 
во свойств, подлежащих привязке модели. Для этого доступны два основных способа. 

Во-первых, можно указывать список свойств для включения в привязку, используя 
атрибут [В1п9] в параметре метода действия, например: 


РБ с АсслопВезо1е ВедузЕетМетек ( [Взпа (ТасЛае = "Маше, Ета11")] Регзой пмурегзоп) 
{ 

а 
} 


Или же можно задавать список свойств, которые должны быть исключены из 
привязки: 


руб11с АсЕтопВезо1е Вед1зехМетюек ( [Вфла (Ехс1аде = "РафеОЕВакЬ")] Регзоп пурегзоп) 
{ 

ИСКЕ: 
} 


Во-вторых, можно применить атрибут [В119] к самому целевому тину. Это правило 
будет применено глобально, ко всем методам действий, где бы данный тип ни привязы- 
вался к модели, например: 
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[В1па (Тос1аае = "Епа11, РабкеоЕвВакеь") ] 
руБ11с с1азз Регзоп 
{ 

риБ11с зЕтг1па Маше { деё; зе ?; } 

руБ11с эзЕхг1па Ема11 { че; зеф; } 

рчБ611с РафеТлие РаееоЕВтуЕв { чее; зе(; } 
} 


Какой из двух способов выбрать, зависит от того, какое правило необходимо устано- 
вить: глобальное или применяемое только в определенном случае привязки модели. 

В любом случае правило Тпс1ае устанавливает “белый” список: привязаны будут 
только явно указанные в нем свойства. С другой стороны, Ехс1иа@4е устанавливает “чер- 
ный” список: будут привязаны все свойства за исключением тех, что явно исключены. 
Применение одновременно Тпс1оаае и Ехс1Таде редко имеет смысл, но если так посту- 
пить, то свойства будут привязаны только в том случае. если они присутствуют в спи- 
ске Тос1оаае и отсутствуют в списке Ехс1оде. 

Если применитт [В1па] и к параметру метода действия, и ко всему целевому тину. 
свойства будут привязаны, только если они разрешены обоими фильграми. Поэтому, 
если свойство ТзАдш?и исключить на целевом типе, то это нельзя будет переопределить 
ни одним методом действия. 


Прямой вызов привязки модели 


Выше было показано, как осуществляется автоматическая привязка модели, когда 
метод действия принимает параметры. Привязку модели можно также запустить вруч- 
ную. Это обеспечит более тонкий контроль над созданием экземпляров объектов моде- 
ли, извлечением входных данных и обработкой онтибок. 

Например. вот как можно переписать действие Вед1з+ехМепьег() из предыдущего 
примера, вызывая вручную привязку модели посредством вызова метода Орда+еМоде1 () 
базового класса контроллера: 


руБ11с АсЕтопВези1еЕ Вед1зеетМептьег () 
{ 
уаг регзоп = пеи Регзоп(); 
ОрааЕеМоае1 (регзоп) ; 
// Или, если вы используете префикс: ОраафеМоде1 (регзоп, "турегзоп"); 
// --. какие-то действия с регзоп 


} 


Этот подход выгодно применять, когда требуется явное управление созданием объ- 
ектов модели. Здесь вы поставляете экземпляр Регзоп для обновления (который может 
быть просто загружен из базы данных) вместо его автоматического создания. 

Метод ОрдасеМодае1 () принимает различные параметры, позволяя выбирать пре- 
фикс ключа входных данных, список параметров для включения или исключения из 
привязки, а также поставщик данных, предоставляющий входные данные. Например. 
вместо РеЁао1{Уа1иеРгоу19ет (который извлекает данные из мест, перечисленных в 
табл. 11.1). можно использовать встроенный поставщик данных ЕохиСо11есЕ1оп, по- 
лучающий свои данные только из Веспез* .Еотт. Ниже показан код. 


руЬ11с АсЕ1опВе51е Вед1зЕегМепоег (ЕогиСо11ес1оп Рог) 
{ 

уаг регзоп = пем Регзоп(); 

ОрааееМо4е1 (регзоп, Фогм.ТоУа1иаеРгох14ехг ()); 

// ... какие-то действия с регзоп 
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Это позволяет элегантно провести модульное тестирование привязки модели. 
Модульные тесты могут запускать метод действия, передавая ЕохиСо11есе1оп с тес- 
товыми данными, что исключает необходимость в применении имитированного или 
фиктивного контекста запроса. Код имеет привлекательный “функциональный” стиль, 
в том смысле, что метод имеет дело только со своими параметрами и не касается объ- 
ектов внепгиего контекста. 


Обработка ошибок привязки модели 


Иногда пользователи вводят значения, которые не могут быть присвоены соответ- 
ствующим свойствам модели, например, неверные даты или текст свойств типа 10%. 
Чтобы разобраться в том, как такие ошибки обрабатываются в МУС Егатемюогк, рас- 
смотрим следующие проектные цели. 


1. Вводимые пользователем данные никогда не должны отбрасываться, даже если 
они не верны. Введенные значения должны сохраняться, чтобы их можно было 
отобразить как часть ошибки проверки достоверности. 


2. Когда ошибок несколько, система должна дать отклик о максимально возможном 
их числе. Это значит, что привязка модели не должна останавливать свою работу. 
столкнувшись с первой же проблемой. 


3. Ошибки привязки не должны игнорироваться. Программист должен суметь рас- 
познать моменты, когда они возникают, и предоставить код для устранения. 


Для достижения первой цели должна быть выделена область для временного хра- 
нения неверных данных. В противном случае, поскольку неверная дата не может быть 
присвоена свойству типа .МЕТ расет1ме, неверно введенные данные будут просто уте- 
ряны. Именно для зтой цели в МУС ЕгатехогК предусмотрена область временного хра- 
нения, реализованная классом Моде15+аке. Эта область также помогает достичь вто- 
рой цели: каждый раз, когда средство привязки модели пытается применить значение к 
свойству, оно фиксирует имя свойства, входное значение (всегда в виде 5119), а также 
все ошибки, вызванные присваиванием. И, наконец, для достижения третьей цели ме- 
тод ОрдаееМоде1 {) завертается генерацией исключения Тпуа110рега&1опЕхсер®1оп 
с сообщением ТЬе моде! оЕ Еуре Еурепаше иаз поЕ зиссеззЕо11у ирдаееа (Модель 
типа имяТипа не была успешно обновлена), если в Моде15аее зафиксированы какие-то 
ошибки. 

Таким образом. поскольку возможны ошибки привязки, необходимо перехватывать 
и обрабатывать исключения. Например: 


руЬ11с АсЕ1опВези1е Бед15%егМепъег () 
{ 
уаг регзоп = пем Регзол (); 
фху 
{ 
ОрдаЕеМоае1 (регзоп); 
// ..- какие-то действия с регзоп 
} 
саЕёсв (1Тпуа11Я9Орега 1опЕхсере1оп ех) 
{ 
// Тоао: предоставить некоторый отклик в пользовательском 
// интерфейсе на основе Моде15таке 


} 


Это вполне разумное применение исключений. В .МЕТ исключения являются стан- 
дартным способом уведомления о невозможности выполнить операцию (они не зарезер- 
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вированы для критичных, редких или “необычных” событий, что бы под ними не подра- 
зумевалось)®. Тем не менее, если вы предпочитаете не иметь дела с исключениями, то 
можете использовать вместо ОрдакеМоде1() метод Тку0рдаееМоде1 (). Этот метод не 
генерирует исключений, а возвращает код состояния типа Боо1. Например: 


РУБ с АсЕ1опВезо1еЕ Вед1зехМепъег () 
{ 
уатг регзопй = пем Регзоп(); 
12 (ТкуО0рдаееМоде1 (регзоп) } 
{ 
// -.. какие-то действия с регзоп 


} 


е1зе 


{ 
// Тодо: предоставить некоторый отклик в пользовательском 
// интерфейсе на основе Моае15+аке 


} 


О том, как реализовать соответствующий отклик в пользовательском интерфейсе, 
вы узнаете в разделе “Проверка достоверности” далее в главе. 


На заметку! Когда определенное свойство модели не может быть привязано из-за некорректности 
входных данных, это не прекращает попыток РеРаз1ЕМоде1В1птаег обработать остальные 
свойства. Это значит, что будет получен объект модели, обновленный лишь частично. 


Если привязка модели используется неявно, те. объекты модели принимаются как 
параметры метода, а не с помощью ОрдаееМоде]1 () или Тгу0рдафемоае1 (), то выпол- 
няется тот же самый процесс, но без уведомления о проблемах генерацией исключения 
Тпуа11Ч9О0река 1опЕхсер( 1 оп. В этом случае наличие проблем привязки определяется 
проверкой свойства Моде15+афе.Т5Уа114, как будет показано ниже. 


Привязка модели к массивам, коллекциям и словарям 


Одной из замечательных особенностей привязки моделей является элегантность по- 
лучения множества элементов данных за раз. Для примера рассмотрим представление, 
в котором с помощью вызова вспомогательного метода визуализируется несколько тек- 
стовых полей с одним и тем же именем: 


Епеег (Ргее оЁ уойг Еауог1ее поу1ез: <Ьхг /> 


<%= Неи1 .ТехЕВох ("тоу1ез") %> «г /> 
<$= Нет .ТехЕВох ("тоу1ез") $%> «г /> 
<%= НЕи1 .ТехЕВох ("тоу1ез") %> 


Предположим, что эта разметка находится в форме, которая отправляет свои дан- 
ные следующему методу действия: 


ручБ11с АсЕ1опВезо1* Роботееь1па (11 5Е<8Ет1п9> поу1ез) 
{ 

ДИ 
} 


В таком случае параметр поу1ез будет содержать по одному элементу для каждо- 
го соответствующего поля формы. Вместо 1151<56+4п9> можно принимать данные в 


? Когла приложение выполняется в режиме выпуска (Кееазе) без присоединенного отладчика, 
исключения .МЕТ редко вызывают сколько-нибудь заметное снижение производительности, 
если только они не возникают десятками тысяч в секунду. 


Глава 11. Ввод данных 367 


виде зЕх3п9[] или даже 115&<5%г1п9> — средство привязки модели достаточно ин- 
теллектуально, чтобы справиться с зтим. Если все текстовые поля будут называться 
пурегзоп .Моулез, то данные автоматически заполнят свойство-коллекцию Мох1ез па- 
раметра пурегзоп метода действия. 


Привязка модели к коллекциям специальных типов 


Пока что все хорогто. Но что если понадобится привязать массив или коллекцию 
произвольного типа, имеющего множество свойств? Для зтого необходим какой-то спо- 
соб объединения наборов связанных элементов управления в группы — по одной группе 
на каждый злемент коллекции. Компонент РеЕау1ЕМоде1В1п9ек ожидает следования 
определенным соглашениям об именовании, что лучше прояснить на примере: 


<% из1па (НЕп1 .Вед1пРоги("Веч15егРегзопз$", "Ноще")) { %> 
<в2>Е1т5е регзоп</р2> 
<91\У>Маше: <%= Ни .ТехЕВох ("реор1е [0] .Маме") %$></91у> 
<а91\у>Епа11 адагезз: <%= НЕш1 .ТехЕВох ("реор1е[0].Ета11") $></а1у> 
<Ч1у>РаЕе оЕ БакЕН: <%= Нё1 .ТехЕВох ("реор1е [0] .РакеоЕВакеЬ") $></а1у> 
<в2>5есопа регзоп</В2> 
<91\>Маше: <%= НЕи1 .ТехёВох ("реор1е[1].Маме") $></а1у> 
<Ч1у>Еща11 адакезз: <%= На .ТехёВох ("реор1е [1] .Ема11") $></а1у> 
<@1у>Рафе оЕ Б1ЕЕВ: <%= Н&и1 .ТехЕВох ("реор1е [1] .РракеоВ1кЬ") %></91у> 


<1приЕ Еуре="виБиле" /> 


Давайте посмотрим на имена элементов управления вводом. Первая группа злемен- 
тов имеет индекс [0] в имени, а вторая — [1]. Для получения этих данных достаточно 
привязать модель к коллекции или массиву объектов Регзоп, используя имя параметра 
реор1е, например: 

ру611с АсЕ1опВези1е ВедАзсегРегзопз (115 <Регзоп> реор1е) 

{ 

Ума 

} 


Поскольку осуществляется привязка ктипу коллекции, компонент РеРао1Моде1В1идег 
будет искать группы входящих значений, снабженных префиксом реор1е[01, 
реор1е [1], реор1е [2] и тд., останавливаясь по достижении индекса, который не со- 
ответствует ни одному входному значению. В этом примере реор1е заполняется двумя 
зкземплярами Регзоп, привязанными к входным данным. 

Явная привязка модели производится так же легко. Понадобится линть указать пре- 
фикс привязки реор1е, как показано в следующем коде: 


рую11с АсЕ1опВези1е Вед1зтетгРегзопз () 
{ 
уаг шуреор1е = пем Т15{<Регзоп> (); 
ОраасеМоае1 (пуреор1е, "реор1е"); 
// 


На заметку! В предыдущем примере шаблона представления для ясности обе группы входных 
элементов управления были записаны вручную. В реальном приложении скорее всего серии 
групп элементов управления вводом будут генерироваться в цикле <% Еог(...) { %>. При 
этом каждую группу можно инкапсулировать в частичное представление и вызывать метод 
НЕ1.ВепаекРатгЕ1а1 () на каждой итерации цикла. 
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Привязка модели к словарю 


Если по какой-то причине метод действия должен принимать словарь вместо масси- 
ва или списка, потребуется следовать модифицированному соглашению об именовании. 
которое более явно оперирует ключами и значениями. Например: 


<% излпа (НЕш1 .Вед1пГоги("ВедтзкегРегзорз", "Нопе")) { $%> 
<12>Е1гзЕ регзоп</р2> 
<1праЕ Еуре="В19аеп" паме="реор1е [0] .Кеу" уа1е="Е1хезКеу" /> 
<а1у>Мате: <%= Н&1 .ТехЕВох ("реор1е [0] .уа1ае.Маме") $></91\> 
<Ч1у>Еща1] а@атезз: <%= НиТ .ТехЕВох ("реор1е[0].уа1ие.Ета11") %></91\> 
<Ч1у>Рафе оЕ БлгЕН: <%= Неи1 .ТехЕВох ("реор1е[0] .уа1ще.РафеоЕВакеЬ") $></а1у> 
<62>5есоп@а регзоп</62> 
<1приЕ Еуре="В1а4еп" паше="реор1е [1] .Кеу" уа№ше="зесоп@Кеу" /> 
<о1у>Маме: <%= НЕп] .ТехеВох ("реор1е [1] .уа1ае.Мапе") $></а1у> 
<Я1у>Ета11 аЧ@ахезз: <%= НЕ .ТехЕВох ("реор1е[1].уа1ае.Ета11") $></91у> 
<Ч1у>раее оЕ Б1гЕР: <%= НЕш1 .ТехЕВох ("реор1е[1] .уа1ае .РабеоЕВак\Ь") $></а1\> 
<1приЕ вбуре="зирм1 Е" /> 

<$ } 5> 


Будучи привязанными к Р1сё1опагу<зетг1па, Регзоп> или ТР1сЕ1опагу<з&г1поа, 
Регзоп>, данные этой формы породят два элемента под ключами Е1уз%Кеу и зесопЯКеу 
соответственно. При этом получить данные можно следующим образом: 


роБ11с АсЕ1опВеза1е ВБед1зЕегРегзопз (ТР1сЕ1опагу<зЕт1та, Регзоп> реор1е) 
{ 

ИУ --- 
} 


Создание специального средства привязки модели 


Выше были описаны правила и соглашения, которые компонент БеЁа1{Моде1В1пдех 
использует для заполнения произвольных типов „МЕТ входными данным. Однако иногда 
может понадобиться обойти все это и установить соверитенно другой способ использо- 
вания входных данных для заполнения объекта определенного типа. Для этого должен 
быть реализован интерфейс ТМоде1Влпадек. 

Например, если требуется получить объект ХРосимепе, заполненный данными ХМГ, 
из скрытого поля формы. то нужна будет совершенно другая стратегия привязки. Не 
имело бы смысла позволять РеРаи1{МоЯ9е1В1паег создавать пустой ХРроситеп®, а затем 
пытаться привязать каждое из его свойств, таких как Е1гзЕМоде, ГазЕМоде, Рагепе и тд. 
Вместо этого понадобилось бы вызвать метод Рагзе () класса ХРоситеп® для интерпре- 
тации входящей строки ХМЕ. Такое поведение можно было бы реализовать с помощью 
следующего класса (он может быть помещен в любое место проекта АЗРМЕТ МУС]: 


раБ11с с1азз ХРосимепЕеВ1пает : 1Моде1Вапает 
{ 
руБ11с оБ]есЕе В1паМоае]1 (СопЕго1ЛехСопеехЕ сопЕго11ехСопеехе, 
Моде1В1п91паСопеехЕ Б1ралюаСопеехЕе) 


// Получить от поставщика значений неформатированное 

// значение после попытки ввода 

зЕк1па Кеу = БлпалпаСопеехе .Моае1Мапе; 

Уа1аеРтоу1аетВези1е уа1 = Б1полпаСопеехеЕ .Уа1аеРтхоу1аех [Кеу]; 

1Е ((уа1Т != пу11) && !36т1п9д.ТзМат1ОкЕтр®У (уа1.АсеетрееоУа1Тае)) { 
// Следовать соглашению, сохранив введенные значения в Моде15афе 
Б1палпаСопеехеЕ .Моае15тате.5еЕМоде1У\Уа1 че (Кеу, уа1); 
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// Попытаться разобрать входные данные 

зЕг1па тисоптпа8Ек1па = ((56г1п9[])уа1 .Вам\Уа1че) [0]; 

ХРосомепЕ рагзеахи1; 

Еку { 
рагзеЯХт1 = ХРосимеп® .Рагзе (1псот1п95%г1п9); 

} 

саесв (Хи1Ехсере1оп) { 
р1па1паСопЕехЕ .Моае15ЕаЕе .АйдаМоде1Етког (Кеу, "Мо® уа11а ХМ"); 
теЕоки па11; 


} 


// Обновить существующую модель или просто вернуть разобранный ХМЫ 


уаг ех15Е1п9Моде1 = (ХРосипеп®) Б1п91паСопеехЕ .Моде1; 
ТЕ (ех1зе1о9Моает != пи11) { 
ТЕ (ехлзе1роМоае1.Воое != пи11) 
ех1$Е1п9Мо9е1 .Боое.Вер1асейтН (рагзеЯХи1 .Воо®); 
е1зе 


ех13(Е1п9Мо@е1 .Ада (рахзеЯХи1 .Воо®); 
хебати ех151п9Мо4е1; 


} 
е1зе 
тееихи рагзеаХхи1; 


} 


// Значение в запросе не найдено 
хееокп пу11; 


} 


Код не так сложен, как может показаться на первый взгляд. Все, что должно сделать 
специальное средство привязки — это принять контекст привязки Моде1Взп91п9Сопеехе, 
который предоставляет Моде1Мапе (имя или префикс привязываемого параметра) и 
Уа1иеркоу1декх, от которого можно получить входные данные. Средство привязки долж- 
но запросить у поставщика значений неформатированные входные данные и попытать- 
ся разобрать их. Если контекст привязки предоставляет существующий объект модели, 
его потребуется обновить, а в противном случае — вернуть новый экземпляр. 


Конфигурирование используемых средств привязки модели 


Новое специальное средство привязки модели не будет использоваться в МУС 
Егате\могК до тех пор, пока это не будет явно указано. При наличии исходного кода 
ХВосомепе средство привязки можно ассоциировать с типом Хросимепе, применив ат- 
рибут, как показано ниже: 


[Моде1В1пдек ($уреоЕ (ХРоситепВапаег) ) ] 
руЬ11с с1аз5 ХРосимепе 
{ 
ДУ ва 
} 


Этот атрибут сообщает МУС ЕгатезхогК. что для каждой привязки Хросопеп® должен 
использоваться специальный класс средства привязки ХРоситепеВ1паек. Однако у вас 
вряд ли есть в распоряжении исходный код ХРоситепе, поэтому взамен придется при- 
менять два альгернативных механизма конфигурирования. 

Первый механизм предусматривает регистрацию средства привязки с помощью 
Моде1Влидетз .Вапает$. Это нужно сделать только однажды, во время инициализации 
приложения. Например, добавьте в С1ора1.азах.сз следующий код: 
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ргеофесееЯ уо1а Арр11саЕ1оп_5%ах® () 
{ 
Вед зсегВоцкез (ВоокетТа 1е. ВопЕез); 


Моде1В1п4ег5 .В1п4егз .Ааа ($уреоЕ (ХРросимепе), пем ХроситепЕВ1паек ()); 
} 


Второй механизм предусматривает указание средства привязки модели для каждого 


случая отдельно. Например, для привязки параметров метода действия используется 
атрибут [Моде1В1пдег]: 


рУБ11с Асе1опвеза1Е МуйсЕлоп ( [Моде1Вапаек (БуреоЕ (Х.осишеп Е В1пдег)) ] Хросипепе хи!) 
{ 

И 
} 


К сожалению, при явном вызове привязки модели указание определенного средства 
привязки модели несколько затруднительно, поскольку по неизвестной причине метод 
Ордатемоае1 () не имеет перегрузки, которая позволила бы сделать это. Решить про- 


блему можно с помощью приведенного ниже служебного метода, который должен быть 
добавлен к контроллеру: 


рглуаее уо19Я ОрдафеМоде1и 1 СозЕотВ1 паех (оБ3есе поае1, 56у1па ргеЕлх, 
ТМоде1В1паехк Б1паех, эеглпа зпстоаде, зСу1па ехс1аае) 
{ 
уаг шоде1Туре = поде1.сСееТуре (); 
Ууаг Б1паАЕЕЕ1Ьаее = пем ВлпаАЕЕЕАБаее { Тистаае = лис1аде, ЕхсТаде = ехс1аае р 
уак Б1п91п9Сопеехе = пем Моде1в1па4паСопеехе { 
Моде1 = поде1, 
Моде1Туре = поае1Туре, 
Моде1Маше = ргеЕа1х, 
Мо@е15Еаке = Моде15{аке, 
Уа1аеРхоу14етг = Уа1лергоу1Аек, 
Ргорег®уЕ11ег = (ргорМаше => БЛПЧАЕЕТЬИе .ТзРкорегЕуА11омеа (ргорМапе) ) 
}; 
Б1паег.В1паМоде1 (Сопего11егСопеехк, Б1ра1паСопеехе); 
1Е (!Моае15аке .ТзУа11а} 
ЕРком пем Тпуа11 9Орега1опЕхсере1от ("Егхог Б1 папа " + поде1Туре.Ео11Мапе); 


} 


Теперь, имея такой метод, вызывать специальное средство привязки достаточно 
легко: 


рур11с АсЕ1опВезо1е МуАсЕтоп () 
{ 
уаг аос = пеи ХРосипепе (); 


ОрдасеМоде1\1 ВСизфошВападех (9ос, "хит", пеи ХРоситепЕР1пдет (), по11, п11); 
И а: 
} 


Таким образом, существует несколько способов назначения средства привязки 
модели. Каким образом в МУС Егатемо к разрешаются конфликтующие настрой- 


ки? Средства привязки модели выбираются в соответствии со следующим порядком 
приоритетов. 


1. Средство привязки, явно указанное для данного случая привязки (примером может 
служить применение атрибута [Моде1В1пдег] к параметру метода действия). 


2. Средство привязки, зарегистрированное в Моде1В1п4дегз .В1паегз для целевого 
типа. 
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3. Средство привязки, назначенное с помощью атрибута [Моде1В1пдек] в самом 
целевом типе. 


4. Средство привязки модели по умолчанию. Обычно им будет Бегац1ЕМоде1В1падегк, 
но это можно изменить, присвоив зкземпляр ТМоде1В1пдег свойству Моде1В1таегз. 
В1пдегз .Бегал1+В1пдек. Это конфигурируется во время инициализации приложе- 
ния, например. в методе Арр11саЕ1оп_З%аге() файла С1ора1.азах.сз. 


Совет. Указание средства привязки модели для конкретного случая (те. первый способ) имеет 
максимум смысла, когда вы больше озабочены форматом входных данных, чем типами „МЕТ, 
на которые они должны отображаться. Например, если иногда требуется принимать данные в 
формате 45ОМ, то в этом случае стоит создать средство привязки /ЗОМ, которое может кон- 
струировать объекты произвольного типа. Это средство привязки не обязательно регистриро- 
вать глобально для какого-то конкретного типа модели, а просто назначать его в определенных 
конкретных случаях. 


Использование привязки модели 
для получения загружаемых файлов 


Вы должны помнить, что при разработке приложения Зройзоге в главе 5 специ- 
альное средство привязки модели использовалось для применения зкземпляров Саг® 
к определенным методам действий. Методам действий не нужно было знать источник 
поступления экземпляров Са’ — они просто появлялись как параметры метода. 

Аналогичный подход применяется в АЗРМЕТ МУС для получения методами действий 
загружаемых файлов. Методу для зтого необходимо всего лишь принять параметр типа 
НЕЕрРОЗЕедЕ11еВазе, а АЗРМЕТ МУС заполнит его (где возможно) данными, соответст- 
вующими загружаемому файлу. 


На заметку! Внутри МУС ЕгатемогК это реализовано в виде специального средства привязки мо- 
дели под названием нЕЕрРоэзхедЕ11еВазеМоде1В1пдег. По умолчанию оно зарегистрировано 
В Моде1В1ваегз .В1паегз. 


В качестве примера позволим пользователю загрузить файл, добавив к одному из 
представлений <Еоги> следующую разметку: 


<Еоги ас&1оп="<$%= 9г1.АсЕлоп ("Ор1Тоаарвофо") %>" 
пеевоа="роз®" 
епсеуре="ио1& 1раг%/ЁЕоги-дафа"> 
ОрТоаЯ а рво®о: <1прие $уре="Е14Те" паше="рНофо" /> 
<1прие суре="зириае" /> 
</Еоги> 


Прием и обработка загружаемых файлов осуществляется в методе действия: 


рую11с Асе1отВези1е Ор1оааРроко (НЕЕрРозееаЕ11еВазе рпофо) 
{ 

// Сохранить файл на диске сервера 

з&т1па Е11еваше = // ... выбрать имя файла 

р'|обо. бауеАз (Ё11епаме); 


// .. или работать с данными напрямую 
Ъусе[] ор1оадедвуеез = вем Буве [рЬобо .СопеепЕТептчеН]; 
рпосо .Тпри 5 геат.ВеаЯ (пр1оааедВу*ез, 0, р8Во®о.СопкепеепаеВ); 


// теперь сделать что-нибудь с ор1оадеаВу*ез 
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На заметку! Дескриптор < Еогт> в предыдущем примере содержал атрибут, который мог показаться 
незнакомым: епсфуре="то1Е1раг% /Еоги-дафа". Этот необходимо для успешной загрузки! 
Если у формы нет такого атрибута, то браузер не сможет загрузить файл — вместо этого он про- 
сто отправит имя файла, а коллекция Ведаезе .Е1Тез будет пустой. (Это особенность работы 
браузеров, не имеющая отношения к АЗРМЕТ МУС.) Вдобавок форма должна быть отправлена в 
запросе РОЗТ (те. иеЕВод="роз("), иначе она не будет содержать никаких файлов. 


В данном примере дескриптор <Еоти> визуализировался через его запись в виде литеральной 
НТМЕ-разметки. В качестве альтернативы дескриптор <Еоги> с атрибутом епсфуре можно 
сгенерировать с помощью метода НЕт1 .ВестиЕоги (), применяя его перегрузку с четырьмя 
параметрами, в том числе параметр по имени ВЕттАСЕт1Ьотез. С другой стороны, литераль- 
ная НТМ! -разметка отличается большей читабельностью, чем передача множества параметров 
методу НЕп1.Вес1пЕоги (). 


Проверка достоверности 


Что такое проверка достоверности? Для многих разработчиков это механизм, кото- 
рый позволяет гарантировать, что входные данные соответствуют определенным шаб- 
лонам (например, адрес электронной почты имеет форму хбу. 7, а имя покупателя не 
превыптает определенной длины). Но как быть с требованиями 0 том, что имена поль- 
зователей должны быть уникальными, или что мероприятия не должны назначаться 
на дни национальных праздников? Считать их правилами проверки достоверности или 
бизнес-правилами? Дело в том. что граница между правилами проверки достоверности 
данных и бизнес-правилами весьма размыта. а то и вовсе не существует 

В рамках архитектуры МУС ответственность за соблюдение всех этих правил воз- 
лагается на уровень модели. В конце концов, это правила, которые должны приме- 
няться в предметной области (даже если речь идет о требовании к строгости пароля). 
Возможность определения любого рода бизнес-правил в одном месте с отделением их 
от конкретной технологии пользовательского интерфейса является ключевым преиму- 
ществом проектирования с применением МУС. В результате получаются более простые 
и надежные приложения, в которых правила не разнесены и не дублируются на раз- 
ных экранах пользовательского интерфейса. Это пример практического использования 
принципа не повторяться. 

В АЗРМЕТ МУС нет ограничений относительно того, как должна быть реализована 
модель предметной области. Это объясняется тем, что даже простейший проект библио- 
теки классов МЕТ комбинируется со всеми технологиями, существующими в зкосистеме 
„МЕТ, предоставляя при этом широчайший диапазон выбора (например, средства досту- 
па к базе данных). Поэтому для АЗРМЕТ МУС совершенно несвойственно вмешиваться в 
ваш уровень модели и навязывать какой-то специфический механизм соблюдения пра- 
вил проверки достоверности. В действительности так оно и есть: вы можете реализовать 
правила так, как вам угодно. Для зтого вполне достаточно простого кода С#. 

С другой стороны, АЗРМЕТ МУС оказывает помощь в построении пользовательско- 
го интерфейса и взаимодействии с пользователями по протоколу НТТР. Для того чтобы 
помочь включить новые бизнес-правила в общий конвейер обработки запросов, в .МЕТ 
МУС принято соглашение относительно способов уведомления АЗРМЕТ МУС о возник- 
ших оптибках, чтобы шаблоны представлений могли отобразить их пользователю. 

Ниже посредством простых примеров включения правил проверки достоверности 
непосредственно в код контроллера будет показано, как работает это соглашение. Позже 
вы увидите, как переместить эти правила на уровень модели приложения, консолиди- 
руя их с произвольными сложными бизнес-правилами и ограничениями базы данных. 
При этом исключается повторение кода, но соблюдаются соглашения АЗРМЕТ МУС от- 
носительно уведомлений об ошибках. 
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На заметку! В предыдущих примерах демонстрировался способ реализации проверки достовер- 
ности с использованием интерфейса тТрафаЕггогТиго. Это только один специальный случай 
в рамках соглашений АЗРМЕТ М\УС относительно сообщения об ошибках. Для начала мы про- 
анализируем лежащий в основе механизм, а позже вернемся к ТРасфаЕ хгогТиРо. 


Регистрация ошибок в Моде1 $ +а+е 


Как было показано ранее в главе, система привязки модели МУС ЕгатехогК в каче- 
стве области временного хранения использует Моде1 5+ афе. В Моде15+а%е хранятся как 
входные значения, которые пытался ввести пользователь, так и детальная информа- 
ция об оптибках привязки. Регистрировать ошибки в Моде15{а&е можно и вручную. Это 
позволит передать информацию об ошибках в представления и даст элементам управ- 
ления вводом возможность восстановить свое предыдущее состояние после неудачной 
проверки достоверности или отказа во время привязки модели. 

Давайте в качестве примера создадим контроллер по имени Воок1поаСопего11ек, 
который позволит пользователям записываться на прием. Собственно приемы модели- 
руются с помощью следующего класса: 


ро611с с1аз$ Арро1ппеп® 
{ 
рор11с зЕг1па С11еп Маше [ дес; зеф; } 
роб11с РабеТлие Арро1пемеп®Рафе { де; зет; } 
} 


Чтобы записаться на прием, пользователь сначала посещает действие МакеВооК1па 
контроллера Воок1паСопе ко11ег: 


руЮ11с с1азз Воок1паСопго11ег : Сопего1Тег 
{ 

[Ассере\Уекрз (НЕЕрУегрз .Сеф) ] 

руБ11с АсЕ1опВезо1Е МаКеВоокКлпч () 

{ 


гефогп Утем(); 


} 


Это действие не делает ничего помимо визуализации представления по умолчанию 
МакеВооК1па .азрх, которое включает следующую форму: 


<% п51п9 (НЕт1.Вед1пЕотм()) { %> 
<р> 
Усиг ваше: <%= Н&т1 .ТехЕВох ("арр® .С11еп Маме") %> 
</р> 
<р> 


Арро1пемеве дафе: 
<$=Ныи .ТехЕВох ("арре.АрролиетепЕЛа®е", РафеТ1те .Мом.ТоброгЕРавеег1та(}} %> 
</р> 
<р> 
%= НЕш1 .СвесКВох ("ассере$Тегтз")} %> 
<1афе1 Еог="“ассер®*зТегиз">Т ассер® Ве Тегиз оЁ ВооК1па</1аре1> 
</р> 


<1прие фуре="зибл1е" уа1ае="Р1асе роок1иа" /> 
<% } %> 
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Обратите внимание, что имена текстовых полей соответствуют свойствам 
Арро1петепе. Это поможет выполнить привязку модели. В целом метод МаКеВоок1по ( 
визуализирует экран, показанный на рис. 11.1. 
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Рис. 11.1. Начальный экран, визуализируемый 
действием МакеВоок1п9 


Поскольку шаблон представления включает вызов метода Ни1 . ВедапРоги (), в ко- 
тором не указан метод действия для отправки данных, форма отправляет их по сгенери- 
ровавшему ее ОВГ. Другими словами, для обработки отправки формы понадобится до- 
бавить еще один метод действия по имени Макевоок1 па (), который будет реагировать 
на запросы РОТ. Ниже показано, как в нем могут обнаруживаться и регистрироваться 
ошибки проверки достоверности: 


[Ассере\Уегьз (НЕ&рУегЬз.Роз*) ] 
рчр11с Асе1опВези1Е МакевооК1 по (Арро1пЕщепе арре, Ъоо1 ассер®зТегиз) 
{ 
1Е (56 у1па.ТзМа11ТОкЕпреу (арр* .С1+1епМапе)) 
Моде1 5 а%хе.АдамМоае1Етгог ("арр*.С11епЕМаце", "Р]еазе епег уотг папе"); 
// Необходимо ввести имя 
ТЕ (Моде15+афе.Тз\Уа11ЯЕ1е19 ("арр+.Арро1петепЕРа*е"))} { 
// Значение РафеТ1ме разобрано. 
// Соответствует ли оно бизнес-правилам приложения? 
1Е (арр®.Арро1пемепЕРаке < РафеТате.Мои.Ра*е) 
Моде1бафе. Аа9МодетЕггох ("арре.Арро1петепЕРасе", "ТЬе дафе раз раззеа"); 
// Эта дата уже прошла 
е1зе 1Е ((арр®.Арро1пбмеп®Раее - РафеТ1те.Мом) .Тофа1Рауз > 7) 
Моде15Сафе.АЧЯаМоде1Етгохг ("арр® .Арро1пеиепЕВа*е", 
пУой сав'{ роок шоге {Пап а меек 1п аауапсе"); 
// Нельзя записываться раньше, чем за неделю 
} 
ТЕ (!ассерезТегтз) 
Моде15 таре .АяаМоде1Егкох ("ассерезТетиз", "Уоц пизЕ ассер® све $егиз"); 
// Необходимо приять условия 
1Е (Моае15таее.Тз\Уа11а) { 
// То ао: сохранить сведения о записи на прием в базе данных или где-нибудь еще 
тефиго Узеи("Сопр1ефеЯ", арр®); 
} е1зе 
теёигр \У1еи(); // Визуализировать то же представление, 
// чтобы пользователь мог исправить ошибки 


} 

Приведенный выше код не претендует на особую злегантность или ясность. Вскоре 
будет показан более аккуратный способ сделать это, а пока здесь просто демонстриру- 
ется самый базовый подход к регистрации ошибок проверки достоверности. 
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На заметку! Тип РасеТ1ме в этом примере используется для того, чтобы показать, что иметь дело 
с ним очень непросто. Поскольку это тип значения, средство привязки модели зарегистрирует 
отсутствие входных данных как ошибку, подобно тому, как оно поступает в отношении неверно 
сформированной строки даты. Чтобы проверить, успешно ли разобрано входное значение, не- 
обходимо вызвать метод Модет5тате.Тз\а119Е1е1а(...). Если разбор завершился не- 
удачей, то нет смысла применять к этому полю любую другую логику проверки достоверности. 


Метод действия принимает входные данные формы в качестве параметров через 
привязку модели. Затем он применяет к ним определенные правила проверки дос- 
товерности наиболее очевидным и гибким способом — выполняя простой код С#. 
Каждое нарушение правила фиксируется в Моде15%аке, с указанием имени злемен- 
та управления вводом, к которому относится ошибка. И, наконец, с помощью метода 
Моае15+ате.Тз\Уа11а (проверяющего наличие зарегистрированных ошибок — либо 
специальным кодом, либо средством привязки модели} принимается решение о том, 
принять запись на прием или заново отобразить тот же самый экран ввода данных. 

Это очень простой шаблон проверки достоверности данных, и он работает доста- 
точно хорошо. Однако если пользователь введет неверные данные прямо сейчас, то он 
не увидит сообщений об ошибках, потому что птаблон представления пока не содержит 
инструкций для их отображения. 


Вспомогательные методы представления 
для вывода информации об ошибках 


Простейший путь заставить ваш шаблон представления отображать сообщения об 
ошибках приведен ниже. Просто поместите вызов Нп1.Уа119а1опбитиаку () где-то 
внутри вашего представления. Например: 


о 


% из1па (НЕ .ВедлиЕоги()) { %> 
<$= НЫп1 .Уа}1За1опбиштаку() %> 
<р> 
... остальной код не меняется ... 
Этот вспомогательный метод генерирует маркированный список ошибок, зафикси- 
рованных в Моде1$тафе. В случае отправки пустой формы будет получен вывод, пока- 
занный на рис. 11.2. 
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Рис. 11.2. Сообщения об ошибках проверки достоверности, 
визуализированные методом НЕм1 .Уа11дае1опбимтаку 
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На этом экране для выделения сообщений об оптибках и элементов управления, к кото- 
рым они относятся, применяются стили С5$. О том, как это сделать, речь пойдет ниже. 

Методу НЕп1 .Уа11За&1опбиммагу() можно также передать параметр по имени 
пеззаде. Это строка, которая будет визуализирована непосредственно над маркиро- 
ванным списком, если имеется хотя бы одна зарегистрированная ошибка. Например. 
можно было бы отобразить сообщение о необходимости исправить ошибки и затем от- 
править форму повторно. 

В качестве альтернативы вместо Нки1 ./а11За1опбишта ху () можно воспользовать- 
ся последовательными вызовами вспомогательного метода НЕи1 .Уа11За<1опМеззасде | 
и поместить сообщения об оптибках в разные места представления. Например. обновите 
МаКеВоок1па.азрх следующим образом: 

<$ 15119 (Ни .ВедуиЕоги()) { $> 

<р> 
Уоце ваше: <%= НЕи1.ТехеВох ("арре.С11еп Маше") %> 


<$= Н&п1.Уа11За1опМеззаде ("арр®.С11епЕМаше") $> 
</р> 


<р> 
Арро1тпемепе да®е: 
<%= Ни] .ТехеВох ("арре .АрротпЕтеперате" , РабеТ1те Мои .ТоЗКотЕрасебх1ла ()) $> 
<%= НЕп1.Уа11За1опМеззаде ("арр+.Арро1петеперае") %> 

</р> 


<р> 
<%= НЕ .СВескВох (“ассер%зТегтз") $%> 
<1аре1 Рот=“ассерезТегтз">Т ассер®е ЕНе Тегиз оЁ ВооК1па</1абе1> 
<%= НЕ] .Уа11ЗаЕ1опМеззаде ("ассер®зТегиаз") %> 

</р> 


<1прие суре="50511е" уа1ае="Р1асе БоокАпа" /> 


Теперь отправка пустой формы приведет к отображению зкрана, показанного на 
рис. 11.3. 
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Рис. 11.3. Сообщения об ошибках проверки достоверности, 
визуализированные методом НЕт1.Уа11Ча1опМеззаве 
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С этим экраном связаны два момента. 


« Откуда поступает сообщение "А уа!че 1$ гедитгеа” (Значение является обязатель- 
ным)? Ведь его нет в контроллере! Причина его появления в том, что во встро- 
енном классе РеЕаи1ЕМоде1В1пдег жестко закодирована регистрация ряда сооб- 
щений об оптибках, связанных, например, с невозможностью разбора входящего 
значения или отсутствием значения для свойства, не допускающего значение 
1и11. В данном случае сообщение появилось потому, что РасеТ1ме является ти- 
пом значения, который не может быть пи11. К счастью, пользователи редко стал- 
киваются с такими сообщениями, поскольку можно заполнять поля значениями 
но умолчанию и предоставлять специальный злемент управления для выбора 
даты. Вероятность увидеть встроенные сообщения еще ниже, если также исполь- 
зуется проверка данных на стороне клиента, о которой речь пойдет ниже. 


« Некоторые из элементов управления ввода выделены с помощью фона. указы- 
вающего на некорректность введенных в них данных. Встроенные вспомогатель- 
ные методы НТМЕ для злементов ввода достаточно разумны, чтобы определить 
факт соответствия злементу Моде15фафе, который имеет ошибки, и применить 
при выводе специальный СЗ$-класс 1приё-уа11даф1оп-еггог. Это позволяет 
устанавливать любые правила С5$ для выделения полей с неверными данными. 
Например, можно добавить следующие стили в таблицу стилей, на которую ссы- 
лается мастер-страница или шаблон представления: 

/* Элемент управления вводом, в котором обнаружена ошибка */ 
.1прие-уа11аа&1оп-еггог { Богаег: 1рх $0114 геа; раскагоипа-со1ог: #Еее; } 
/* Текст, визуализированный с помощью Неи1.У\Уа11да&1опМеззасае () */ 

. Ете1Ч-уа11аак1оп-еггог {[{ со1ог: геа; } 


/* Текст, визуализированный с помощью Н®и1.Уа11Ча& 1опбоитаку() */ 
.уа11да&1оп-зпоитагу-еггогз { Еоп®-метаН®: ро1а; со1ог: геа; } 


Поддержка состояния элементов ввода 


Если теперь отправить форму, частично заполненную данными, то набор сообще- 
ний об ошибках соответствующим образом сократится. Например, если введены имя и 
дата, но не отмечен флажок | ассер! Ше Тегтз о Воокта (Принимаю условия записи на 
прием), будет получен вывод, показанный на рис. 11.4. 
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Рис. 11.4. При отправке частично заполненной формы набор 
сообщений об ошибках сокращается 
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Здесь следует отметить основной момент: после повторной визуализации формы ра- 
нее введенные данные (имя и дата) сохраняются. В АЗРМЕТ \еБЕоги1$ иллюзия сохра- 
нения состояния достигается с помощью механизма \Ле\уЭ Ее, но в АЗРМЕТ МУС такого 
механизма нет. Каким же образом сохраняется состояние? 

И снова в игру вступает соглашение. Оно требует. чтобы элементы управления вво- 
дом заполняли себя данными, взятыми из следующих мест, перечисленных в порядке 
приоритетности. 


1. Значение, введенное во время предыдущей несостоявшейся попытки вода, кото- 
рое зафиксировано в Моде15+фаее ["имя"] .Уа1ще.АкфетреедУа1ще. 


2. Явно указанное значение (например, <%= НЕп1.ТехЕВох ("имя", "Некоторое 
значение") $%>). 


3. Значение из структуры У1емража, извлекаемое вызовом У1емрата.Еуа1 ("имя") 
таким образом, У1еирафа["имя" ] отдается преи ество перед У1еирафа. 
р реимущ р 
Моде1. имя). 


Так как средства привязки модели фиксируют все попытки ввода значений в 
Моде15фате независимо от их корректности, встроенные вспомогательные методы 
НТМЕ естественным образом заново отображают предыдущие значения после сбоя про- 
верки достоверности или привязки модели. И поскольку это имеет максимальный при- 
оритет, даже заменяя явно указанные значения, эти явно указанные значения следует 
воспринимать как начальные значения злементов управления вводом. 


Выполнение проверки достоверности 
во время привязки модели 


Проанализировав работу предыдущего примера записи на прием, можно заметить, 
что проверка достоверности проходит в два этапа. 


® На первом зтапе компонент реёаи1ЕМоде1В+пдег применяет некоторые правила 
форматирования данных при разборе входящих значений и пытается присвоить 
их объекту модели. Например, если входное значение арр®.Арро1пещепеРаее не 
удается разобрать как РакеТ1ме, то реЕап1+Моде1В+пдек регистрирует ошибку 
проверки достоверности в Моде15тате. 


* На втором зтапе, после завершения привязки модели, метод действия 
МакеВоок1п9 () проверяет привязанные значения на предмет соответствия биз- 
нес-правилам. Если он обнаруживает нарушения этих правил, то также регистри- 
рует их как ошибки в Моде15 таке. 


Вскоре вы узнаете, как усовершенствовать и упростить второй зтап проверки досто- 
верности. Но сначала будет показано, каким образом реЁаи1+Моде1В1пдег выполняет 
проверку достоверности, и как настроить зтот процесс но своему усмотрению. 

В классе Бегач1ЕМоде1В1идег предусмотрены четыре виртуальных метода, которые 
связаны с проверкой входных данных. Все они перечислены в табл. 11.2. 

Если во время привязки модели возникают какие-либо ошибки разбора или 
исключения установки значения свойства, то компонент БеЕаз1Моде1твВ+пает 
также их перехватывает и регистрирует как оптибки в Моде15та+е. 

Поведение по умолчанию, описанное в табл. 11.2, отражает работу встроенной в 
каркас МУС ЕгатехогК поддержки интерфейса тразаЕккогтиго. Если класс модели 
реализует этот интерфейс, он будет запрашиваться для проверки достоверности во вре- 
мя привязки данных. Именно зтот механизм лежал в основе проверки достоверности в 
примерах приложений Рапу[пу{ез$ в главе 2 и Зроиз юге в главах 4-6. 
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Таблица 11.2. Переопределяемые методы проверки достоверности 
из класса РеЁац1Моде1В1паек 


Метод Описание Поведение по умолчанию 

ОпМодеТОрдае 119 Запускается в момент, когда Ничего не делает; просто возвращает 
РеЁаи1{Моде1В1паег соби- $гие. 
рается обновить значения всех 
свойств специального объекта 
модели. Возвращает значение 
Ъоо1 , означающее разрешение 
или запрет выполнения привязки. 

ОпМоде1ТОрдатея Запускается после попытки Проверяет, реализует ли объект мо- 
РеЁЕап1+Моде1Ваидег обно- дели интерфейс трасаЕггогТьЕо. 
вить значения всех свойств спе- Если да, запрашивает его свойство 
циального объекта модели. Еског для нахождения любого со- 

общения об ошибке уровня объекта и 
регистрирует непустое значение как 
ошибку в Моде1 5х ате. 

ОпРгорегеу\а119а{119 — Запускается каждый раз, когда Если тип свойства не допускает зна- 
РеЁЕа11{Моде1В1паег соби- чения пи1 1, а входящее значение 
рается применить значение к равно пот 1, регистрирует ошибку в 
свойству специального объекта Мо4е15тате и блокирует значение, 
модели. Возвращает значение возвращая Еа1зе. Иначе возвращает 
Боб, говорящее о том, следуетли &гое. 
применять значение. 

ОпРгорегеу\а11Аафея — Запускается каждый раз, когда Проверяет, реализует ли объект мо- 


ОеЕаз1ЕМоде1В1паехг приме- 
няет значение к свойству специ- 
ального объекта модели. 


дели ТРасаЕггогТиЕо, Если да, оп- 
рашивает индексированное свойство 
{515 [ргорегуМапе | в поисках со0б- 
щений об ошибке уровня свойства, по- 
сле чего регистрирует любое непустое 
значение как ошибку в Моде15ъате. 


Для реализации другого вида проверки достоверности во время привяэки данных 


можно создать класс, унаследованный от БеГац1{Моде1В1пдект, и переопределить в 
нем соответствующие методы, перечисленные в табл. 11.2. Затем специальное средст- 
во привязки необходимо подключить к МУС ЕгатеуогК, добавив следующую строку в 
файл с1ора1.азах.сз: 


ргофесееа хо1а Арр11са®1оп_5Ъаг® ()} 
{ 
Вед1з$егВоп®ез (ВочкеТар1е.Воц%ез); 
Моде1Вапдегз .Вапаегз .Реац1ЕВ1п4ег = пем МуМоде1В1тпаег(); 
) 


Однако потребность в наследовании РеГац1Моде1В1тдег возникает редко, осо- 
бенно в качестве способа соблюдения бизнес-правил. По умолчанию компонент 
Рег аз1ЕМоде1В1пдег сам обнаруживает и выдает простые сообщения об оптибках раз- 
бора. Но привязка модели — это всего лишь внешняя инфраструктура, которая собира- 
ет входящие данные из пар “ключ/значение” НТТР-запроса в объекты .МЕТ. Так почему 
же она должна отвечать за определение или соблюдение бизнес-правил? 

Бизнес-правила должны соблюдаться на уровне предметной области. В противном 
случае модель предметной области вообще не нужна. Давайте теперь рассмотрим спо- 
собы реализации бизнес-правил. 
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Перенос логики проверки достоверности 
на уровень модели 


К этому моменту уже должно быть понятно. как в АЗРМЕТ МУС регистрируются на- 
рушения правил, как соответствующие сообщения отображаются в представлениях и ка- 
ким образом сохраняются значения, указанные при попытках ввода. В рассматриваемом 
примере с записью на прием специальные правила проверки достоверности были реали- 
зованы встраиванием в метод действия. Это нормально для небольших приложений, но 
приводит к тесной связи определения и реализации бизнес-логики с конкретным поль- 
зовательским интерфейсом. Такая тесная связь является вполне приемлемой практикой 
в АЗРМЕТ \еЪЕогилз, поскольку эта платформа предлагает встроенные элементы управ- 
ления проверкой достоверности. Однако при этом не достигается идеального разделения 
ответственности, и со временем возникают следующие практические проблемы. 


®* Повторение. Устанавливаемые правила приходится дублировать в каждом поль- 
зовательском интерфейсе, к которому они применяются. Как и любое нарушение 
принципа “не повторяться”, повторение приводит к лишней работе и открывает 
возможности для несогласованности. 


® Неясность. Без единого централизованного определения бизнес-правил поте- 
ря контроля над разрабатываемым проектом — всего лишь вопрос времени. Вы 
не сможете упрекнуть нового члена команды разработки в том, что в созданном 
средстве он проигнорировал какое-то запутанное правило; ведь никто ему не объ- 
яснил необходимость его соблюдения. 


® Ограниченный выбор технологий. Из-за того, что модель предметной области за- 
висит от конкретной технологии пользовательского интерфейса, не удается легко 
построить новый клиент на основе ЭЙуег ЦЕ или, кажем, версию приложения для 
1РБопе без необходимости заново реализовывать все бизнес-правила, даже если 
они определены. 


® Произвольное расхождение между правилами проверки достоверности. и бизнес- 
правилами. Конечно, добавление к форме чего-то вроде “средства нроверки за- 
полнения обязательного поля” может быть и удобно, но как насчет таких правил. 
как “имена пользователей должны быть уникальными” или “только привилегиро- 
ванные клиенты могут приобретать товар при ограниченном его количестве”? Это 
нечто большее, чем проверка достоверности в рамках пользовательского интер- 
фейса. Но почему зти правила должны быть реализованы по-разному? 


Интерфейс трафаЕггогТрЕо 


В приведенных ранее примерах было показано, что для присоединения логики про- 
верки достоверности к классам модели можно использовать интерфейс ТрафаЕггокТр Ро. 
Это делается легко и хорошо подходит для неболыпих приложений. Однако при разработ- 
ке крупного приложения необходимо масштабировать его сложность. В связи с этим воз- 
можностей интерфейса ТрафаЕггогТпЕо может не хватить по следующим причинам. 


* Как упоминалось ранее, на самом деле привязка модели не должна заниматься со- 
блюдением бизнес-правил. Почему уровень модели должен полагаться на то, что 
уровень пользовательского интерфейса (те. контроллеры и действия) корректно 
вьышолнит проверку достоверности? Для гарантии соответствия проверка досто- 
верности все равно должна завершаться моделью предметной области. 


* Вместо проверки достоверности состояния объектов часто имеет больше смысла 
проверить корректность выполняемой операции. Например, может потребовать- 
ся внедрить правило, гласящее, что запись на прием в выходные дни не разре- 
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шена никому, кроме менеджеров, обладающих определенными полномочиями. 
В этом случае речь идет не о действительности или недействительности записи 
на прием, а о корректности самой операции. Такую логику легко реализовать не- 
посредственно в методе Р1асеВоок1па (Боок1п9) на уровне предметной области, 
но добиться того же самого за счет присоединения интерфейса ТракаЕгкогТиЕо 
к объекту модели ВооК1па довольно непросто. 


® Интерфейс ТРасаЕггогТипЕо не предлагает никаких средств сообщения о множе- 
ственных ошибках, относящихся к одному свойству, или множественных ошиб- 
ках, относящихся ко всему объекту модели, кроме конкатенации всех сообщений 
в одну строку- 

® Компонент БеЁаи1ЕМоде1В1пдег пытается применить значение к свойству только 
тогда, когда в запрос включена соответствующая пара “ключ/значение”. В прин- 
ципе обойти проверку достоверности определенного свойства можно, просто уда- 
лив пару “ключ/значение” из НТТР-запроса. 


Это не признание непригодности интерфейса ТракаЕггохТпЕо. Он удобен во многих 
случаях, в частности, в небольших приложениях с менее четкой ролью модели предмет- 
ной области. Именно поэтому он используется в различных примерах настоящей книги. 
Однако в более крупных приложениях полный контроль над операциями предметной 
области лучше предоставить уровню модели зтой предметной области. 


Реализация проверки достоверности в операциях модели 


Достаточно абстрактной теории — давайте обратимся к коду. Предоставить коду 
предметной области право блокировать определенные операции (вроде сохранения за- 
писей или фиксации транзакций), если он решит, что правила нарушены, на самом деле 
очень просто. 

Предположим, что в предыдущем примере объект Арро1птиепе может быть зафик- 
сирован или сохранен вызовом метода Зауе (), реализованного следующим образом: 


ру611с уо1@ бауе () 
{ 
уаг еггогз = бесво1еуУ1о1а1оптз (); 
ТЕ (егкогз.Сочое > 0) 
&Ьгом пем Ва1еЕхсере1оп (еггогз}; 
// Тодо: сохранить в базе данных или в каком-то другом месте 
} 
рг1уасе МашеуаТеСо11есЕ1оп Сееко1е\!1о1а 1 опз () 
{ 
уаг егкогз = пеи Мапеуа]оеСо11есеТот (}; 
1Е (зЕх1лп9д.ТзМа11ОкЕпреу (С11еоЕМаце) ) 
еггогз.Ада ("С]14епЕМапе", "Р1еазе епеег уопг папе"); 
// Необходимо ввести имя 
1Е (Арро1тпемепеБасе == БабеТ1ще .М1тпУа1ае} 
егкогз.Ада ("Арро1пемепЕРафе", "Арро1пстепЕБаее 1$ геди1геа"); 
// Необходимо ввести Арро1обтепЕБаее 


е1зе { 
1Е (Арро1пемепЕРаее < Рабет1ие .Мом.Рате) 
еггогз .АдаЯ ("Арро1тпЕтепЕРаее", "Тре дафе Ва$ раззеа"); 


// Эта дата уже прошла 
е1зе 1Е ((Арро1пемепЕРафе - Рабетуме.Мом) .Тоса1Вауз > 7) 
еггогз .Ада ("Арро1обмепЕРаее", "Уоц сап'Е БооК поге {вап а меекК 11 адхапсе"); 
// Нельзя записываться раньше, чем за неделю 


} 


тегсигп еггог8; 
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Теперь объект модели Арро1петепе берет на себя ответственность за соблюдение 
собственных правил. Не важно, сколько разных контроллеров и методов действий (или 
совершенно других технологий пользовательского интерфейса) попытаются сохранять 
объекты Арро1пЕтепе — все они будут субъектами одних и тех же правил, нравятся 
они им или нет. 

А что насчет исключения Во1еЕхсере1оп? Это простой специальный тин исключе- 
ния, который может хранить коллекцию сообщений об ошибках. Его можно поместить 
в проект модели предметной области и применять повсюду в решении. Ниже приведено 
определение класса Ко1еЕхсере1оп: 


руБ11с с1азз Ко1еЕхсерсфоп : ЕхсерЕ1оп 


{ 


рур11с Мамеуа1иеСо11есЕ1от Еггогз { деф; рг1фуаке зет; } 
раБ11с Ва1еЕхсерЕ1оп (зЕх1па Кеу, зЕх1пд уа1ае) { 
Егкогз = пеи Мапеуа1аеСо11есе1от { {Кеу, уа1ае} }; 


} 


руб11с Ко1еЕхсер®1оп (Матеуа1аеСо11есЕ1оп егкогз} { 
Еггког$ = еггог$; 


} 
// Заполнить Моде15афер1сЕ1отаку для генерации отклика 
// в пользовательском интерфейсе 
раБ11с у014 СоруТомоде15аее (Моде1 5 тасер1се1опагу поде15тафе, зЕк1па ркеЕ1х) 
{ 
ГогеасВ (зЕг1пд Кеу 1 Еггог$) 
Гогеасв (36г1пд уа1ае 1ш Еккогз .СесУа1аез (кеу)) 
поет тате .АаМоде1Егкох (ргеЁ1х + "." + Кеу, уа ше); 


} 
} 


На заметку! В случае помещения во1теЕхсерЕ1оп в проект модели предметной области без уста- 

новки ссылки на сборку ЗузЕет. Иер .мМус. 911 обращаться к типу Моде1 $+аъерзсефопагу 
непосредственно из Во1еЕхсерЕ1 оп будет невозможно. Вместо этого СорутомоЧе1$сате () 
придется реализовать в проекте М\С как расширяющий метод Во1еЕхсерЕ1 оп. 
Чтобы избежать жесткого кодирования сообщений об ошибках в коде предметной области, в 
класс Ко1еЕхсере1оп можно добавить возможность хранения списка ссылок на злементы в 
файле ВЕЗХ, которая позволит методу СоруТоМоде1 $ ахе (} извлекать сообщения об ошиб- 
ках во время выполнения. Это добавит поддержку локализации и обеспечит улучшенную кон- 
фигурируемость. О локализации речь пойдет в главе 15. 


Теперь можно упростить метод действия МаКеВоок1та() контроллера ВооК1пс 
СопЕго11ег следующим образом: 
[АссереУетЪз (НЕЕрУекЬз$ .Роз{) ] 


раБ11с АсЕ1опВеза1е МакеВоок1па (Арро1петерЕ арре, 6оо1 ассерезТегиз)} 
{ 
1Е (!ассерезТегтз) 


Моде15тате .АааМоае1Етгохг ("ассерезТегиз", "уой шазЕ ассере ЕВе Еегтз"); 
1Е (Моае15хафе.ТзУа11а) { 
Еку { 
арре.захе (); 
} 
саесВ (Ки1еЕхсерЕ1оп ех) { 
ех.СоруТоМоде1 5 аее {Моае15тафе, "аррь"); 


у 


} 
} 
тесагио Моае15ате.Т5\а11а ? У1еи ("Сопр1Тетеа", арр®) : Узеи(); 
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Если бизнес-правила требуют, чтобы для каждой записи на прием было предусмот- 
рено согласие с условиями записи, в классе Арро1опепе имеет смысл создать свойство 
АссерезТегтз типа Боо1 и проверять его внутри метода бееВо1е\1о1аЕ1о1п$ (). Это 
зависит от того, к чему относится данное правило: к модели предметной области или к 
особенностям конкретного пользовательского интерфейса. 


Реализация сложных правил 


Следуя описанному шаблону, произвольные правила легко выразить в простом коде 
С#. При этом не понадобится изучать какой-то специальный АРГ-интерфейс либо ог- 
раничиваться проверкой определенных шаблонов форматирования или выполнением 
определенных сравнений свойств. Правила могут даже зависеть от других данных (та- 
ких как уровень запасов} или от ролей, к которым принадлежит текущий пользователь. 
Генерация исключения, когда необходимо прервать операцию, является всего лишь осо- 
бенностью базового объектно-ориентированного программирования. 

Исключения являются идеальным механизмом для выполнения этой работы, потому 
что их невозможно игнорировать, и они могут содержать описание причин отказа опе- 
рации. Контроллерам не нужно заранее сообщать. каких оптибок следует ожидать. или 
даже в каком месте может быть сгенерировано исключение Ко1еЕхсер Топ. До тех пор, 
пока это случается в пределах блока Егу.. .сафсь, информация об оптибке автоматиче- 
ски “всплывет” на уровень пользовательского интерфейса без каких-либо дополнитель- 
ных усилий со стороны разработчика. 

Предположим, что к примеру записи на прием добавлено новое бизнес-требование: 
допускается только по одной записи на прием в день. Надежный способ обеспечить это 
состоит в наложении в базе данных ограничения ОМТООЕ на столбец. соответствующий 
свойству Арро1петереВаее класса Арро1пемепе. То, как именно это делается, зависит 
от используемой платформы базы данных. После наложения упомянутого ограниче- 
ния любая попытка отправки конфликтующую запись на прием вызовет исключение 
За1ЕхсереТов. 

Обновите метод Зауе()} класса Арро1пемеп*, чтобы он транслировал исключение 
за1Ехсере1тов в Ка1еЕхсеретоп, как показано ниже: 


ра611с уо1а зауе () 
{ 


хаг еггогз = бесво1еуУло1ае1отз (); 


ТЕ (егкгогз.Соцое > 0) 
ЕВхом рем Ки1еЕхсерЕ1 от (еггогз); 
Еку { 
// Тодо: действительно сохранить в базе данных 
} саесЬ (За1Ехсер&1оп ех) { 
14 (ех.Меззаде.Сопфа1т5 ("ТХ РАТЕ ОМТООЕ")) // Имя ограничения в базе данных 
ЕВком пеи Ки1еЕхсер оп ("Арро1петепЕРаее", "богку, а1геа4у Боокеа"); 
// Запись для этой даты уже сушествует 
ФЬгои; // Повторно сгенерировать любые другие исключения, 
// чтобы избежать вмешательства в них 


} 


Ключевое преимущество проверки достоверности на основе модели заключается в 
том, что изменение или добавление бизнес-правил осуществляется без затрагивания 
контроллеров и представлений. Новые правила автоматически распространяются на 


уровень связанного с ними пользовательского интерфейса без дополнительных усилий 
(рис. 11.5}. 
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Рис. 11.5. Распространение ошибки от модели на уровень пользовательского интерфейса 


Проверка достоверности клиентской стороны (Чауа$ сир) 


Существует один очень важный аспект проверки достоверности. который до сих пор 
игнорировался. В веб-приложениях большинство пользователей ожидают немедленного 
отклика по результатам проверки достоверности, те. до отправки чего-либо на сервер. 
Это называется проверкой достоверности клиентской стороны и обычно реализуется с 
применением кода ЗауаЗсире. Простая проверка достоверности на стороне сервера на- 
дежна. но не слишком удобна для пользователей, если только не подкреплена проверкой 
достоверности клиентской стороны. 

В АЗРМЕТ МУС 1.0 нет какой-либо встроенной поддержки проверки достоверности 
клиентской стороны. Причина в том, что существует масса инструментов для такой 
проверки достоверности от независимых разработчиков (включая инструменты с от- 
крытым исходным кодом, которые интегрированы с |@чету}, и они согласованы с идео- 
логией АЗРМЕТ МУС, что позволяет легко воспользоваться любым из них. По мере вы- 
работки пгаблонов использования, возможно, команда разработчиков из Мсгозой либо 
добавит собственные вспомогательные средства проверки достоверности клиентской 
стороны в будущую версию АЗРМЕТ МУС. либо предложит руководства и технологию 
для облегчения интеграции сторонних библиотек, предназначенных для проверки дос- 
товерности клиентской стороны. 

Однако пока основным путем реализации проверки достоверности на стороне клиен- 
та в АБРМЕТ МУС остается применение какой-нибудь библиотеки Зауа$спре от незави- 
симых поставщиков с ручной репликацией выбранных правил проверки достоверности 
в шаблоны представлений. В следующей главе будет показан пример применения для 
этих целей библиотеки |Очегу. Основной недостаток зтого подхода связан с дублирова- 
нием логики. В идеале следовало бы найти какой-нибудь способ генерирования логики 
проверки достоверности клиентской стороны непосредственно из правил, изложенных 
в коде модели, однако в общем случае отображение кода С# на коду ауабси!рЕ невозмож- 
но. Существует ли решение этой проблемы? Разумеется! 


Генерация кода проверки достоверности 
клиентской стороны из атрибутов модели 


В .МЕТ доступно множество сред проверки достоверности серверной стороны, кото- 
рые позволяют выражать правила декларативно, с использованием атрибутов. В их чис- 
ло входят МНфегпае.МаНазог и Саз@е УаЙЧайоп. Можно даже воспользоваться сборкой 
Зузтем.СотропепЕМоде1 .ПафаАппокаЕ1ол5 . 911 от М1сгозой (включенной в .МЕТ 3.5} 
для аннотирования класса ВооК1пд, как показано ниже: 
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роЬ11с с1аз$ Арро1тпемепе 
{ 
[Веса1гея] [ЗЕх1потепоеЪ (50) ] 
ру11с зЕх1пда С11епЕМаме { деб; зе{; } 
[Веча1хеЯ] [РафаТуре (РафаТуре .Раке)] 
ру611с РабеТ1те Арро1пепепераее { деё; зес; } 
} 


Вместе с небольшой дополнительной инфраструктурой, которая называется средстт- 
вом выполнения проверки достоверности, эти атрибуты можно использовать как он- 
ределение некоторых правил проверки достоверности на стороне сервера. Более того, 
непосредственно из этих правил можно сгенерировать конфигурацию проверки досто- 
верности клиентской стороны и привязать ее к существующему инструменту проверки 
достоверности на стороне клиента. После этого проверка достоверности на клиентской 
стороне просто выполняется и автоматически остается синхронизированной с прави- 
лами серверной стороны. 

Как пояснялось ранее, дополнительные бизнес-правила произвольной сложности 
по-прежнему можгут быть реализованы с помощью простого кода С#. Эти правила бу- 
дут применяться только на стороне сервера, потому что не существует общего способа 
отобразить эту логику непосредственно на код Зауабсире. Простые правила формати- 
рования свойств, выраженные декларативно (т.е. большинство правил), могут быть ав- 
томатически продублированы правилами клиентской стороны, тогда как сложная про- 
извольная логика останется исключительно на сервере. 


Быстрое подключение х\а! 


Если описанный выше подход к проектированию вызвал интерес, стоит ознако- 
миться со средой х\а1 (ПЕЕр://хуа1 . содер1ех.сот/}. Это свободно доступный проект 
с открытым исходным кодом, который добавляет проверку достоверности клиентской 
стороны к АЗРМЕТ МУС. Среда хУ\Уа] позволяет комбинировать выбранные механизмы 
проверки достоверности серверной и клиентской стороны, обнаруживать декларатив- 
ные правила проверки достоверности и преобразовывать их в код Зауабсире на лету. 
В настоящее время хУ\Уа! можно использовать со сборкой бузфеп. Сотропеп%ЕМоает . 
РафаАппосаЕ1от5 .911, средами СазЦе УаНЧайоп, МыЪегпаце.МаНазог, 1Очегу УаНаацоп 
и встроенными средствами проверки достоверности АЗРМЕТ \МеЪЕогтз. Для поддержки 
дополнительных сред можно написать собственные подключаемые модули. 


Мастера и многошаговые формы 


На многих веб-сайтах реализован пользовательский интерфейс в стиле мастеров, ко- 
торые позволяют провести посетителя по многошаговому процессу, подтверждаемому 
в самом конце. Мастера следуют принципу последовательного раскрытия (ргобтезауе 
91зс<1о5иге), при котором пользователи не перегружаются десятками вопросов, часть из 
которых может не иметь для них значения. Вместо этого на каждой стадии предлагает- 
ся ответить лишь на небольшой набор вопросов. В зависимости от выбора, сделанного 
пользователем, может существовать несколько путей прохождения мастера, и пользо- 
вателю всегда предоставляется возможность вернуться и изменить ответы, данные на 
вопросы. На последней стадии обычно выводится типичный экран подтверждения, по- 
зволяющий пользователю проверить и подтвердить сделанный выбор. 

В АЗРМЕТ МУС доступно практически неограниченное количество способов реали- 
зации таких пользовательских интерфейсов. Ниже показан лишь один пример построе- 
ния четырехшагового мастера регистрации, работа которого описана рабочим потоком 
на рис. 11.6. 
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Начало Основные сведения: ввод имени и адреса электронной почты 


Дополнительные сведения: ввод возраста и хобби 


Подтверждение 


Фиксация в базе данных 


Рис. 11.6. Рабочий поток для примера четырехшагового мастера 


Навигация по множеству шагов 


Начнем с создания начального класса контроллера Кед1зЕ ха 1опСопего11ет с пер- 
выми двумя шагами: 


ручЬ11с с1азз Вед1зегаЕ1опСопЕхо11ех ; Сопфго11ег 
{ 

риЮ11с АсЕ1о0Вез11Е Ваз1срефа113 () 

{ 

гесаги Утеи(); 

} 

руБ11с АсЕ1опВеза1е ЕхЕгарефа11$ () 

{ 


гесого У1еи(); 


} 


Теперь создайте начальное представление для действия Ваз1срееа11$ (), щелкнув 
правой кнопкой мыши внутри метода Ваз1сПефа11$() и выбрав в контекстном меню 
пункт АДА Мем/ (Добавить представление). Для нового представления можно оставить 
имя по умолчанию — Ваз1сПефа11$. Оно не должно быть строго типизированным. 
Содержимое представления приведено ниже: 


<в2>Кед1зЕкаЕ1оп: Ваз1с Яаефа113</62> 
Р1еазе епфег уоиг 4еГа113 
<% и31094 (НЕ .Вед1пЕогт()) { $> 
%$= НЕи1.Уа14аае1опбиттаку () %> 
<р>Мате: <%= Неи1 .ТехеВох ("Маше") $></р> 
<р>Е-та11: <%= Ныа1.ТехеВох ("Ета11"} $></р> 
<р><1приЕе суре="зиби1е" папе="рехЕВиееот" уа1ае="МехЕ >" /></р> 


Результат проделанной работы можно сразу же проверить в браузере, зайдя на ЧВЬ 
/Вед1зЕга&1оп/Ваз1срефа11з (рис. 11.7). 

Как видите, произошло не слишком много. Щелчок на кнопке Меж (Далее) приводит 
к отображению того же самого экрана, а не к переходу на следующий шах. И это вполне 
естественно, поскольку логика, которая бы обеспечила перемещение на следующий шахт, 
пока еще не реализована. 


ВазсОетайз - УНодсяз Имею”. 


са10=516524Аеизуанол-Ввуспения 


ыы 


‚ ВелутаНон: Вас деаЙ5 


1 РЕазе ещег топе детайе 
} 


Мате: 
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Рис. 11.7. Первый шаг мастера 
Давайте добавим ее: 


руБ11с с1азз Вед1зе ка 1опСопЕго11ег : Сопёхо11ехг 


{ 


руб11с АсЕ1опВезо1е Ваз1сПефа113 (зЕх1па пехЕВиееоп) 


{ 
1Е (прехеВаееоп != 1011) 


тебакп Кед1хгесеТоАсЕ1оп ("ЕхЕгарефа115"); 


хебатп Узеи(); 
} 
ручЮ11с АсЕтопВези1е 1 
{ 


1Е (БаскВаееоп != пи11) 


ьхсгарефа11$ (5&х1па БаскВиЕеоп, зЕк1па пехЕВо®Фоп) 


тебагп Вед1хгесеТоАсЕ1оп ("Ваз1срефа115"); 


е1зе 1Е (пехЕВаеФоп != по171) 

гтебагп Кед1лгес®ТоАсЕтоп ("СопЕ1км") ; 
е1зе 

тебакп \1ем(); 


} 


Что здесь происходит? Вы заметили, что в шаблоне пр 


едставления Ваз1срефа11$. 


азрх в вызове Н&п1 .Вед1оРоги() не указано целевое действие? Это заставит форму 
отнравить данные по тому же ОВГ, по которому она была сгенерирована (те. тому же 


методу действия). 


Вдобавок, после щелчка на кнопке отправки браузер посылает пару “ключ/значе- 


ние” Кесиез® .ЕКоги, соответствующую имени зтой кнопки. 


Таким образом, методы дей- 


ствий могут определить, на какой кнопке был совершен щелчок (если был), привязывая 
параметр зЕг1па к имени кнопки и проверяя входное значение на предмет равенства 


0011 (неравенство пи11 означает, что на кнопке был совер 


тен щелчок). 


И, наконец, добавьге аналогичное представление для действия ЕхЕгаОера11з в файл 


с представлениями по умолчанию /У1еиз/Кед1зегкае1оп/1 


<р2>Вед1зекаЕ1от: Ехега Яефа11з</62> 
ЧазЕ а 61 поге 1пЕо р1еазе. 
% из1па (НЕи1 .ВедаиРогм(}) { %> 
<$= НЕи1 .Уа11даЕ1опбиттаку () %> 
<р>Аде: <%= НЕп1.Тех®Вох ("Аде") $></р> 
<р> 
НоББ1ез: 


[хегарефа11$.азрх: 


%= Не] .ТехеАгеа ("НобБЮ1ез", по11, 3, 20, по11)} $> 


</р> 


388 часть И. АЗРМЕТ МУС во всех деталях 


<р> 
<1приЕе суре="зобла Е" паме="БаскВиееов" уа1ае="< Васк" /> 
<Чприе вБуре="зот16" папе=“"пехЕВиееой" уа]ае="Мехе >" /> 


В результате был создан вполне работоспособный механизм навигации. как показа- 
но на рис. 11.8. 


В нерпосавозы 57 20ВУЛЕсЗНаногиВан [22 ПВР ВВИЯ 


Веб гайоп: Вас деаЙ5 


 Реазе евкег уотк дев 


| Маше: 


Рис. 11.8. Мастер позволяет перемещаться вперед и назад по экранам 


Тем не менее, при текущем состоянии дел все данные, введенные в полях формы, 
просто игнорируются и немедленно теряются. 


Сбор и сохранение данных 


Механизм навигации — это самая простая часть задачи. Гораздо сложнее организо- 
вать сбор и сохранение значений полей формы, даже когда они не отображаются на те- 
кущем шаге мастера. Начнем с определения класса модели данных Вед1з+гае1опрака, 
который можно поместить в напку /Моде1: 


[Зег1а117аЪ1е] 

руБ11с с1азз Вед1зткаЕ1опрафа 

{ 
руБ11с зЕг1п9 Маме { деёе; зеб; } 
руБ11с зЕг1п9 Ета11 { деё; зеЕ; } 
ру611с 116? Аде { дее; зе; } 
ру11с зЕг1п9 НоББТез { де; зес; } 


} 


Новый зиземпляр класса Ведч1зегае1опрака будет создаваться каждый раз, когда 
пользователь входит в мастер. Поля этого экземпляра заполняются данными, введен- 
ными на любом шаге, что позволяет сохранять их между запросами и в конце каким- 
то образом зафиксировать (например, поместить в базу данных или использовать для 
генерации новой записи пользователя). Класс Кед1зЕ ка 1опрафа помечен атрибутом 
[3ех1а11ха6ю1е], потому что он будет сохраняться между запросами за счет сериали- 
зации в скрытое поле формы. 
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На заметку! Этот способ отличается от обычного для АЗР МЕТ М\УС сохранения состояния, когда 
ранее введенные значения извлекаются из Моде1 5 сате. Техника с Моде15+а®е не подходит 
для многошагового мастера, поскольку тот теряет содержимое всех элементов управления, ко- 
торые не отображаются на текущем шаге. Вместо Моде15+ате в рассматриваемом примере 
применяется подход, больше похожий на реализованное в АЗР МЕТ \МебРопт$ сохранение дан- 
ных формы путем их сериализации в скрытое поле. Если вы не знакомы с этим механизмом 
или с сериализацией в целом, прочтите врезку “Механизм \Мемые и сериализация” далее в 
этой главе, где объясняется как механизм, так и связанные с ним сложности. 


Чтобы создать и сохранить объект вед1зЕ га 1опрата между запросами, модифици- 
руйте Вед1 зЕ га фопСопего11ег следующим образом: 


рую11с с1аз$ Вед1зекаЕ1опСопеко11]ек : Сопегоек 
{ 
руб11с Вед1зЕкаЕ1опПафа гедрафа; 
ргобессей отегг1ае уо1а ОпАсеторЕхесис1та (Аст опЕхеси1паСопеехе Е11еегСопсехе) 


{ 


хедПаба = (Зег1а117а 1010115 .Пезег1а11те (ВечиезЕ.ЕРоги["гедГаба"]) 
2? Тетшррака [ "хедрафа"] 
?? пем Вед1зЕгаЕ1опраа ()} аз Кед1зЕкае1опрака; 


Тгу0рааеемоде1 (хедрафа)}; 
} 
ркобесбеа охегг19е уо1а ОпВезя1ЕЕхесисеа (Везо1(ЕхесисейСопсехЕ Е11]+ехСореехе) 
{ 


1Е (Е11ЕегСопеехЕ.Вези1 1$ Кеа1кесеТоВосЕевези1е) 
ТепрВрафа ["хедГафка"] = гедрафа; 
} 


// ... остальной код не изменяется 


} 


Как видите, добавилось довольно много кода. Ниже даны соответствующие пояснения. 


® Перед каждым запуском метода действия в методе ОпАсе1опЕхесиЕ1та (} пред- 
принимается попытка получить существующее значение для гедрака. Сначала 
он пытается десериализовать значение из коллекции Ведаез+ .Еогм. Если это не 
удается, он ищет значение в Тепррака. Если оно не обнаруживается и там, созда- 
ется новый экземпляр. И, наконец, явным образом вызывается привязка модели 
для копирования любых отправленных значений полей формы в гедрака. 


® После выполнения каждого метода действия в методе Опвезо1{Ехесиевеа(} прове- 
ряется резульгат, чтобы выяснить, не выполняет ли он перенаправление к другому 
методу действия. Если перенаправление имеет место, то единственный способ со- 
хранения данных гедбата состоит в их помещении в Тепррафа. Это метод и дела- 
ет, чтобы Опвези1ЕхесоЕ1па () мог извлечь оттуда данные в следующий раз. 


Совет. Если подобного рода мастера приходится разрабатывать часто, можно инкапсу- 
лировать предыдущую логику в собственный обобщенный базовый класс контроллера 
\1хахЧаСопего11ег<тТ>, где <Т> специфицирует тип сохраняемого объекта данных. В та- 
ком случае класс КедтзЕгаЕ1опСопЕко11ег лучше унаследовать не от СопЕхо11егх, а от 
1 хакЧСопего11ег<Вед1зега&1опрака>. 


Также обратите внимание, что в коде имеется ссылка на 5ех1а11гак10п0%11$. Это 
всего лишь неболышой вспомогательный класс, который несколько упрощает взаимо- 
действие с АРГинтерфейсом сериализации „МЕТ. Код этого класса может поместить в 
любое место проекта: 
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риуб11с збаЁ1с с1азз бег1а11гаЕ1о104115 
{ 
руБ11с зфаЕ1с зЕт1па бегхла112е (оБ]есе оЪ]) 
{ 
// Примечание: об) должен быть помечен как [3ех1а11та61е] 
// или реализовать ТЗег1а11та 1 е 
ЗЕх1роомЕ1ек иг1фег = пем Зех1поме1 еек (); 
пем ГозРогтабстег () .3ег1а117е (ик1фег, оЪ)); 
териги иг1фег.ТобЕг1юч (); 


} 


риб11с зрсаЕ1с ою)]есе Безет1а11те (зег1па Чака) 
{ 
ЗЕ (Заба == по11) 
хебаги пи11; 
тегакп (пеи ГозРогмасфег()) .Резег1а11хе (Чака); 


} 


До сих пор никакие данные для отображения представлений в У1ехПафа.Моде1 не 
передавались. а зто значит, что поля формы каждый раз сначала будут пустыми. Это 
легко исправить: измените методы действий Ваз1сПефа11з () и Ехегарефа11$() таким 
образом, чтобы при вызове У1еи() для визуализации представления они передавали 
гедрака как строго типизированный объект модели. Ниже показано, как следует моди- 
фицировать Ваз1сПе{фа11$ (): 


ру611с АсЕ1опВезо1Е Ваз1сПефа113 (56х1п9 пехЕВиЕеоп) 
{ 
Е (пехеВиЕбоп != по11) 
гегокп Вед1гесеТоАсЕ1 оп ("ЕхЕгкаПОефа113"); 
хееигп \1еи (хедрафа); 
} 


Измените метод Ех гарефа113 () так, чтобы он каким-то образом применял гедрафа 
к своему представлению. После этого все поля форм в обоих представлениях будут авто- 
матически заполнены с использованием значений свойств из хедрахка. 

И, наконец, чтобы избежать потери содержимого объекта модели в конце каждо- 
го запроса, сериализуйте его содержимое в скрытое поле формы по имени гедрафа 
(метод ОпАсе1опЕхеси 19а (), который знает, как восстанавливать значение из этого 
поля, уже реализован}. Обновите оба шаблона представлений (Ваз1срера115.азрх и 
ЕхегаПера11$ .азрх}, добавив новое скрытое поле: 


<$%$@ ТирохгЕ Машезрасе="пространство имен, в которое был помещен 
класс Зег1а11гаЕ1оп0Е115" %> 
<!-- Оставить без изменений --> 
% и51пд (НЕ .Вед1юЕоги()) { $%> 
<%= НЕ1 .НЗЯ4еп ("хедрафа", Зек1а11ха1о0п0%115.Зех1а11 ге (Моде1)) `%> 


<!-- Оставить без изменений --> 


Вот и все! Теперь любые вводимые данные будут сохранены во время навигации впе- 
ред и назад по страницам мастера. Этот код достаточно обобщен для того, чтобы после 
добавления в Вед1 з&га®1опрафа новых полей, они также автоматически сохранялись. 


Завершение мастера 


В заключение примера понадобится добавить методы действий для шагов подтвер- 
ждения (СопЕ1ги ()) и завершения (Сотр1ефе ()): 
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руЮ11с с1азз Вед1з6кае1опСопего11ек :; СопЕхо11ек 
{ 
// Остальной код не изменять 
РУЧБТ1с АсЕзопБезотЕ СопЕ1ги (56х19 БаскКВыеЕоп, зехапа пехеВоееоп) 
{ 
Е (БаскКВаЕеЕоп != пот) 
тебакп Вед1хгесЕеТоАсе1 от ("ЕхЕгарефа115$"); 
ефзе 1Е (пехЕВаЕбоп != по11) 
хебаги Вед1кесЕТоАсЕ1оп ("Сопр1еее"); 
ефзе 
тебагп У1ем (хедрата); 


} 


РУБТ1с АсЕ1опКези1 Сопр1ефе () 

{ 
// Тодо: сохранить кедрафа в базе данных и визуализировать 
// завершающее представление 
тебаги Сопфепе("ОК, ме’ке Яопе"); 


} 


Затем добавьте представление для действия СопЕ1км в /У1емз/Вед1зекае1оп/ 
СопЕ1 гт.азрх, которое содержит приведенный ниже код. Для удобства выбрано строго 
типизированное представление с типом модели Вед15ЕхаЕ1опрака. {В качестве альтер- 
нативы Моде] .Мате, например, можно заменить У1емРафа.Еуа1 ("Маше") .) 


<р2>СопЕ1ки</В2> 
Р1еазе сопЕ1гм ЕВаф уоик дефа115$ аге соггесь. 
<$ 08119 (НЕп1.ВедлоЕоги()) { %> 


<%= НЫп.Н1адеп ("геддафа", 5ех1а11та1000%113.5ех1а11хе (Моде1)) %> 

<Я1у>Маме: <5><%= Нет] .Епсоае (Моде1 .Мате) %></6></ад1х> 

<а1у>Е-та11: <р><%= Неп1.Епсоде (Моае1 .Епа11)$></Ъ></д1у> 

<Ч1у>Аде: <ю><%= Моае1.Аде %></5></91у> 

<а1у>Норр1ез: <ю><%= Нем1.Епсоде (Моде1 .НоБб1ез) *></Ь></91у> 

<р> 
<1приЕ суре="зиб1е" паме="ЬаскВие оп" уа1иае="< ВасКк" /> 
<1приЕ суре="зиби1е" паме="оехЕВиееоп" уа1ае="Мехе >" /> 

</р> 

<$ } %> 


Чтобы код заработал, потребуется добавить объявление <*% Нпроге $%> для пространства 
имен, содержащего класс 5ет1а117а610оп0%115, как зто делалось в Ваз1срефа113.азрх 
и ЕхЕгаПефа115 .азрх. И на зтом работа завершена: создан мастер, который позволяет 
выполнять навигацию вперед и назад, сохраняя при этом данные, введенные в полях, 
имеет зкран подтверждения и довольно простой финальный экран (рис. 11.9). 


Проверка достоверности 


Вы наверняка заметили, что в рассмотренном примере не было предусмотрено ни- 
какой проверки достоверности вводимых данных. Чтобы добавить ее, можно воспользо- 
ваться любым описанным ранее способом. В целях демонстрации определим правила, 
добавив в класс Кед1 з& гае1опрафа реализацию интерфейса ТрасаЕггохТпЕо: 


[Зех1а117ха1е] 
рчЬ11с с1аз5 Вед1з& га 1опраба : ТРафаЕккохгТиЕо 
{ 


/* Оставить свойства без изменений */ 
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РУБ11с зЕк1па 01$ [5Ег1п9 соТашпМате] 
{ 
чее { 
1Е ((соТитпМате == "Мате") && зЕх1па.Т5М№11ОкЕпреу (Мапе) ) 
хебаги "РТеазе епфег а паме"; // Необходимо ввести имя 


1Е ((соТитпМате == "Ета11") && !15\Уа11ЯЕпа11АЯагез$ (Ета: 1) ) 
хегогп "Р1еазе епфегк а уа11@Я етаз1 аЯ9гезз$"; 
// Необходимо ввести правильный адрес электронной почты 


1 ((софитпМаше == "Аде") && 'Аде.НазУа1ле) 
хееаки "РТеазе епфег а патег1с аде"; 
// Необходимо ввести возраст в виде числа 


хебагп па; 
} 
} 
РУБ с зЕк1па Еккок { деЕ { кебагп пи11; } } // Не требуется 
} 


Теперь необходимо, чтобы на каждом шаге мастера пользователю нельзя было дви- 
гаться далыше, если привязка модели сообщила о проблемах. 


2 Е: $ 


5 а БЕ нкже Но расе. 


й Аве: 948 


Бака за; асе 


| Совйтт 


| Рвазе сопйта Ша усе Черай$ аге соггесе. 


нь 
= 


} . Мене: Зете 

| Е зай: зетееханнИе. сот 
_ Аве 948 
‚ Нобыез: ЕаБ ше ну аое 


отт трон 
т < Васк || Мех > | 


Рис. 11.9. Готовый мастер в действии 
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Измените методы Ваз1сОефа11$() и Ех гаОефса113 (} следующим образом: 


руб11с Асе1опВезиа1е Ваз1сПОефа11$ (56109 пехЕВие®оп) 


{ 


ТЕ ((пехЕВиббоп != по11) && Моде15+аее.тТз\а11а) { 


} 


теби 


} 


рую11с Асе1опВези1е ЕхЕгарефа113 (36 г1п9 БаскВибкоп, зс:1п9 пехЕВуЕбоп) 


{ 


тебигп Вед1кес®То‘Асетоп ("ЕхегаПефа115"); 


гл Утем (гедрафа); 


ТЕ (ФаскВиееоп != пи11) 


е1зе 


е1зе 


} 


тесаги Вед1хесеТоАсЕ1 оп ("Ваз1срефа115") ; 


1Е ((пехЕВиЕфоп != пи11) && Моде16еафе .тзУа119а) 


теЕбиго ВедтеесЕТоАсЕтоп ("СопЕ1 ти"); 


тебатгп Утем (гедрака); 
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Вот и все. Поскольку шаблоны представлений уже содержат вызов НЕи1 .Уа119а&1оп 
Зиптаху (), любые обнаруженные ошибки будут отображены в маркированном списке 
(рис. 11.10). 


Е рез ее ИИ Е 


ыы о ый 


{ Раазе епеег зовг Чебай5 


= Рерсв снега ине 
= Релха овеег а та оао 2бфге5$ 


Рис. 11.10. Ошибки проверки достоверности препятствуют 


переходу к следующему шагу мастера 


На заметку! Когда пользователь завершает работу с мастером, обычно производится передача 
экземпляра Ведч1зЕхаЕ1опрафа на уровень модели, где могут выполниться такие операции, 
как сохранение его в базе данных. Несмотря на то что проверка достоверности осуществляется 
на каждом шаге мастера, все равно данные должны быть проверены еще раз в коде модели 
предметной области, иначе есть риск принять неверные данные. Вполне возможно, что пользо- 
ватель, которому известен ЦВЕ действия СопЕ1 гм, начнет выполнение мастера прямо с зтой 
точки, минуя все предыдущие шаги. Для надежности применяйте проверку достоверности на 
уровне модели перед фиксацией данных или завершением операции. 
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Механизм Мем$е и сериализация 


В некотором смысле показанный на рис. 11.6 рабочий поток проще построить на платформе 
АЗР.МЕТ \М!еБРогтз, потому что ее механизм Мем\ае автоматизирует функциональность пред- 
ставления данных, которую пришлось строить вручную?. 


Если вдруг вы не знакомы с М\еБРогтив, то знайте, что Мем/{{е — это коллекция, в которую можно 
помещать на хранение любой сериализуемый объект. 


При визуализации формы АЗРМЕТ \ММебЕРогтз сериализует содержимое зтой коллекции и сохра- 
няет его в скрытом поле по имени __УТЕМЗТАТЕ. Позднее, когда браузер выполнит обратную 
отправку формы, входящие значения _ УТЕИЗТАТЕ десериализуются и используются для авто- 
матической реконструкции содержимого коллекции Мем{е. Встроенные элементы управления 
\М/ебРогт$ автоматически используют Мемае для сохранения собственных значений, даже ко- 
гда они не отображаются на зкране. Этот механизм работает точно так же, как реализованный в 
предыдущем примере, за исключением того, что вместо применения подхода, ориентированного 
на злементы управления (хранение состояния индивидуальных элементов управления в скрытом 
поле), в примере используется подход, ориентированный на модель (сериализация и сохранение 
объекта Веч1з+гаЕ1опрака). 


Механизм Мем{ае в АЗРМЕТ Ме Рогтз (и очень похожий на него механизм Сопно Зе) час- 
то приводит к чрезмерному возрастанию размеров НТМЕ-страниц (100 Кбайт закодированных с 
помощью Вазеб4 данных мало кому понравятся), вызывает ошибки “Лем {е 15 пуапа” (недо- 
пустимый \Мем5{ее) и затрудняет работу по написанию специальных элементов управления, что 
обычно ведет к недовольству со стороны пользователей. Это, пожалуй, наиболее порицаемое 
средство платформы \М\еБРогтл$. Тем не менее, в качестве общего шаблона проектирования оно 
совершенно адекватно: веб-разработчики всегда сохраняли данные в скрытых полях форм, а это 
средство переносит такой подход на следующий уровень формализации и абстракции. Проблема 
реализации МебРогтз в том, что механизм Мем Ее настолько сильно автоматизирован и интег- 
рирован в платформу, что, помимо воли, получается сохранять слишком много объектов, даже 
тех, которые порождают чудовищные объемы данных при сериализации (например, РафаТаь1е}. 
Хотя средство Мем{айе можете выборочно отключать для индивидуальных элементов управле- 
ния, многие злементы \!ебРогтз работают правильно только когда оно включено. Поэтому для 
решения этой главной проблемы приходится сохранять жесткий ручной контроль над сериали- 
зуемыми данными, как это было в предыдущем примере. 


Огромным преимуществом сериализации данных состояния на стороне клиента является устой- 
чивость: даже если пользователь оставит свой браузер открытым на всю ночь, он сможет продол- 
жить процесс на следующий день (или на следующей неделе}, не теряя данных и не потребляя 
памяти сервера. Однако существуют и ограничения. 


* Производительность. Сериализация может оказаться медленной. Хорошо, если нужно сериа- 
лизировать и десериализовать только несколько небольших объектов в каждом запросе, но при 
перемещении крупных объемов данных очень скоро производительность ощутимо снизится. 


* Сериализуемость. Обрабатываемый объект данных должен быть сериализуемым. Следова- 
тельно, все его поля также должны быть сериализуемыми. Это нормально для строк, целых 
чисел, булевских значений, но не очень хорошо для некоторых типов .МЕТ или специальных 
объектов предметной области, которые не могут быть сериализуемыми до тех пор, пока не 
будет написан специальный код сериализации. 


* Пропускная способность и безопасность. Данные хранятся на стороне клиента. Поскольку 
они включаются в каждый запрос (полезная нагрузка РОЗТ) и в каждый ответ (скрытое поле 
формы), то даже несмотря на их кодирование по алгоритму Вазеб4, ничто не помешает зло- 


Кроме того, в АЗРМЕТ \еЪЕоглиз имеется встроенный элемент управления тина мастера (его 
описание даваться не будет; на то есть документация). Продемонстрированный здесь под- 
ход. может послужить отправной точкой для построения собственных интерактивных рабо- 
чих потоков и поведения. 
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умышленнику прочитать и подделать их. Проблему подделки можно решить за счет добавления 
кода НМАС (см. раздел “Служебный класс НМАС” далее в этой главе), что и делает механизм 
\Мем ме \МебЕРогт$ по умолчанию. Следует отметить, что проблема подделки не становится 
обязательной, если на финальной стадии перед фиксацией предусмотрена проверка досто- 
верности данных. 


Механизм \Мем Зе удобен в качестве общего шаблона веб-разработки. Однако понадобится 
тщательно обдумать, что с его помощью необходимо сохранять. 


На заметку! В качестве альтернативы сериализации экземпляров Вед1 5 га 1опПафа в скрытые 
поля формы их можно сохранять в коллекции безз1оп [] посетителя. В этом случае проблемы 
снижения производительности или пропускной способности на стороне клиента возникать не 
будут; фактически объекты вообще не будут нуждаться в сериализации. Тем не менее, сохране- 
ние объектов Вед1 зЕ каЕ1опрака в без з1ол [] также имеет свои недостатки. Прежде всего, 
в коллекции безз1оп[] нельзя использовать фиксированный ключ, иначе, когда посетитель 
откроет более одной вкладки в браузере, они начнут влиять друг на друга, и понадобится ка- 
кой-то способ решения этой проблемы. К тому же, что более важно, коллекция 5езз1олп [] 
является изменчивой — ее содержимое может быть удалено в любой момент для освобожде- 
ния памяти сервера, — поэтому нужна система, которая изящно справится с утерей данных. 
Посетителям не понравится частая выдача сообщения “Зогту, усиг зезоп паз ехрией” (сеанс 
устарел). В конечном итоге хранение данных в 5ез51оп[] может быть удобным, но не на- 
столько устойчивым, как сериализация в скрытое поле формы. 


Верификация 


Интернет не может считаться безопасным местом, поскольку в нем водятся спамеры 
и прочие негодяи, которые так и ищут способы создать проблемы для веб-приложения. 
Однако чересчур тревожиться по этому поводу также не следует — за счет чуть более 
тщательного проектирования можно противостоять или предотвратить большинство 
злоупотреблений. Ниже описаны два известных приема. которые несложно реализовать 
с помощью АЗРМЕТ МУС. (В главе 13 рассматриваются более серьезные угрозы, о кото- 
рых следует знать любому разработчику веб-приложений.) 


Реализация компонента САРТСНА 


На многих веб-сайтах некоторые формы защищаются от отправки спама, требуя от 
посетителя ввести серию символов, отображенных в виде графической картинки, при- 
мер которой показан на рис. 11.11. 


УеИсайоп | 


Реасе епрег зе еще Ферауе Беких. 


МовулЕ- 


УеййсаНов еегя: 


Рис. 11.11. Компонент САРТСНА, который будет реализован в этой главе 
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Идея здесь состоит в том, что человек сумеет прочитать такие символы, а компь- 
ютер — нет. В результате автоматические заполнения форм блокируются, а ввод че- 
ловеком обрабатывается, но ценой небольшого неудобства. Это средство, называемое 
САРТСНА (Сошреёау Ащотацед РиБс Таня Тез 10 ТЕ Сотпрефегз апа Нишапз Араг — 
полностью автоматизированный открытый тест Тьюринга по распознаванию людей и 
машин; ими .саресва.пеф/), в последние годы получило широкое распространение. 


Внимание! Применение компонента САРТСНА может вызвать проблемы доступности, ктому же его 
общая целесообразность весьма сомнительна. Современные технологии оптического распо- 
знавания символов (ОСН) настолько хороши, что читают не хуже или даже лучше большинства 
людей, особенно если оптимизированы под определенный генератор изображений САРТСНА. 
Если злоумышленники планируют получить выгоду от взлома установленного на сайте компо- 
нента САРТСНА, то они наверняка достигнут в этом успеха, но если сайт не представляет для 
них особой ценности, то простого компонента САРТСНА окажется достаточно, чтобы защитить- 
ся от спама. Несмотря на ограничения САРТСНА, веб-разработчики часто внедряют их и неред- 
ко спрашивают, как это делается. Именно поэтому настоящий пример был включен в книгу. 


Далее будет показано, как построить компонент САРТСНА. Он будет реализован в 
форме вспомогательного метода НТМИ, по имени НЕт1.СаресЪа(), который можно до- 
бавлять к любому шаблону представления для вывода изображения САРТСНА. На той 
же странице представления также будет предусмотрено текстовое поле, где посетитель 
должен будет ввести свое решение относительно символов на изображении САРТСНА. 
Когда посетитель отправит форму одному из методов действий, будет вызван статиче- 
ский метод СаресваНе1рег.\Уех1ЕуАпдЕхр1гебо1аезоп () для определения правильно- 
сти введенного ответа. 

Ниже представлено детальное описание работы будущего компонента САРТСНА. 


® Метод НЕм1.Саресва() сгенерирует некоторый случайный текст и сохранит его 
в коллекции 5езз51оп[] посетителя под случайным ключом СОТ (который назы- 
вается СОТ вызова (спаШепве СТО). Затем он визуализирует скрытое поле фор- 
мы, содержащее этот СОТО. Кроме того, метод визуализирует дескриптор <1т9> 
со ссылкой на метод действия, генерирующий изображение, передав ему СОШ 
вызова в качестве параметра строки запроса. 


® Метод действия, генерирующий изображение. использует переданный параметр 
СОТ для извлечения текста решения из коллекции 5езз1оп[] посетителя и ви- 
зуализирует искаженное изображение зтого текста. Поскольку метод действия за- 
прошен через дескриптор <1т9>, изображение будет показано в браузере. 


® При последующем вызове методу СаресваНе1рег.Уег1ЕуАпдЕХхругебо1о ет оп () 
передается СОТ вызова, извлеченный из скрытого поля данных входной формы, 
а также введенное пользователем решение. Метод СарестаНе1рег.Уег1 ЕуАпа 
Ехр1гебо1ое1оп() извлечет текст решения из коллекции 5езз1оп[] посетителя, 
сравнит его с введенным и вернет булевское значение. указывающее на соответ- 
ствие. В то же время он удалит злемент с решением из коллекции безззоп[]. 
чтобы предотвратить его повторное использование (это называется атакой по- 
вторением (геру аНасК)). 


Создание вспомогательного метода НТМЕ 


Давайте начнем с построения вспомогательного метода НТМГ, который отобразит 
тест САРТСНА. Создайте новый статический класс по имени СаресЪаНе1рег в любом 
месте проекта веб-приложения (например, в папке /Не1регз) и поместите в него при- 
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веденный ниже код. Как было описано выше, он генерирует случайный текст решения 
вместе с СОШ вызова и возвращает дескриптор <1п9>, а также скрытое поле формы. 


рую11с збаЕ1с с1аз5 СареспаНе1рег 
{ 
1о6егпа1 сопзЕ з5г1ид безз1опКеуРхеЕ1х = "__Саресва"; 
ре1фуафе сопзЕ зЕг1п9 ПадЕкогтае = "<119 зис=\"{0}\" />"; 
рую11с зЕаЕ1с з6х1п9 СаресВа (613 Не1Не1рег №1, зЕг1па папе) 
{ 
// Выбрать СИТО для представления этого вызова 
зЕг1п9 сва11епдеби1а = би19.Мемби19 () .Тобек1п9 (); 


// Сгенерировать и сохранить произвольный текст решения 
уаг зезз1оп = 6611. У1еиСопфехе .НеЕрСопеехе. $езз10п; 
зеззлот [5езз1опКеуРтеЕ1х + сва11епаеби1а] = МакеКапдотбо1 а 1оп (); 


// Визуализировать дескриптор <1п9> с искаженным текстом, 

// плюс скрытое поле, содержащее СОТО вызова 

уУаг ик1Не1рег = пем Ок1Не1рег (№61 .У1емСореехЕ .Вечиез Сопеех®); 

зЕг1па ие = ик1Не1рег.Ас®1опт ("Вепдег", "СаресБаТтаде", пем{сра11еподеСи1а}); 

тебиго зЕг1пд.РЕогта* (ТиоКоктае, их1) + №51 .Н1Чеп (папе, сва11епдебСи1а) ; 
} 
ре1уафе зкаф1с зеклоа Макекапдот$о1Тае1оп () 
{ 

Вапдом гпа = оем Вапдом(); 

106 1епаЕеВ = год.Мех® (5, 7); 

сБах[] БаЁ = пем свак[1еп9%В]; 

Рок (101 = 0; 1 < 1епдЕВ; 1++) 

БиЕ[1] = (сЪаг) ('а' + ход .Мехе (26)); 
тебиги пем з6г1па (БаЕ); 


} 


На заметку! Прежде чем можно будет вызывать № $1 .Н1адеп (), потребуется добавить опера- 
тор ч51па для пространства имен бузеет.Меь .Мус.НейТ. Это пространство имен, в кото- 
ром находится расширяющий метод. 


Для использования зтого вспомогательного метода создадим очень простую страницу 
регистрации пользователя. Она не будет на самом деле выполнять регистрацию, а пона- 
добится только для того, чтобы можно было вызвать вспомогательный метод САРТСНА. 
Ниже приведен простой класс контроллера по имени Вед1зЕхаефопСопето1Тех (он никак 
не связан с другими классами Вед1з{ ка 1опСопеко11екг, встречающимися в книге}: 


рию11с с1а55 Вед1зЕ ха 1опСорето11ег : Сопеко1Лег 
{ 

рую11с У1еиВези1Е Тадех() 

{ 


тесакп У1ем (); 
} 
руб11с Асе1опВези1е Зима ЕВед1зекас1оп () 
{ 


теЕико Сопбепе ("Извините, пока не реализовано."); 


} 


Очевидно, что для действия ТпЯех понадобится представление, поэтому добавьте 
новое представление, щелкнув правой кнопкой мыши внутри метода Тпдех () и выбрав 
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в контекстном меню пункт Ада \Ме\м/ (Добавить представление). Для данного примера 
представление не должно быть строго типизированным. 

Поскольку СарЕсва() является расптлиряющим методом, доступ к нему можно по- 
лучить только после импортирования его пространства имен. Для этого добавьте объ- 
явление <%@ ТпрогЕе %> в начало Тпаех. азрх, прямо под объявлением <%@ Раде $%>. 
Объявление должно выглядеть примерно так: 


<%@ ТпрокЕ Мапезрасе="УоцгАрр.Не1регз" $%> 


После этого можно внести некоторое содержимое в представление Тпдех. азрх: 


<62>Вед1зЕкак1оп</н2> 
<% 95119 (НЕ .Вед1оЕоги ("боби ЕВед1зкаф1оп", "Кед1зЕхаЕ1от")) { %> 
Р]еазе гед1з%ек. Т1%'53 могЕН 1+. 
<1>То 9о: АзК Еог ассоцпе аефа113 (паше, адатгезз, 
реЁ'з пате, Ста11 раззмока, ефс.)</1> 
<63>Уег1 Е1 саб 1оп</в3> 
<р>Р1еазе епеег Пе 1ефегз 915зр1ауеЯ ре1ои.</р> 
= НЕ .Саресва ("муСаресва") $%> 
<91у>Уег1Е1сае1оп Леефегз: <%= НЕТ .ТехЕВох ("ак кетре") %></а1у> 
<р><1приЕ буре="зи ие" уатие="<ириу хед1зЕкаЕ1оп" /></р> 
<$ } %> 


Если теперь запустить метод действия тпдех контроллера Кед1 Е хаб1опСопеко11ек, 
посетив ОБТ. /Вед1зега&1оп, он визуализирует страницу, показанную на рис. 11.12. 
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Рис. 11.12. Экран регистрации на данном этапе разработки 


Почему же на месте изображения САРТСНА мы видим пиктограмму отсутствующего 
изображения? Если вы просмотрите исходный НТМЕ-код (для зтого в ИцегпеЕ Ехрюгег 
нажмите и отпустите клавишу <А!1> и выберите пункт меню Вид» Просмотр НТМЕ- 
кода), то увидите, что метод Ней1.Саресва() сгенерировал следующий код разметки: 


<1та зтс="/СаресЪаТтаде/Вепдехг?сва11епдеби19=а205с872-83е... ит.д." 
<1прие суре="Р1 адепт" папе="муСаресва" 19="туСаресьа" уа1е="9205с872-83е... 
ит.д." /> 


В коде предпринимается попытка загрузить изображение из /СарЕсватмаде/ 
Вепаек, но пока еще нет контроллера СаресваТтадеСопфко11ех, поэтому и выводится 
пиктограмма отсутствующего изображения. 


Глава 11. Ввод данных 399 


Визуализация динамического изображения 


Для получения действительного изображения добавьте новый класс контроллера 
Саре сваТтадеСопего11ет, содержащий метод действия Вепдег (). Как было описано 
в начале примера, он должен извлечь текст решения, который соответствует входному 
СОТО вызова, и затем отправить динамически сгенерированное изображение для этого 
текста обратно в поток ответа. Визуализация динамического изображения в „МЕТ, наря- 
ду со всеми сложностями создания и освобождения ресурсов СУ, потребует достаточно 
большого объема кода, который не слишком интересен или информативен. Ниже при- 
веден полный листинг кода, но помните, что набирать его вручную не нужно, поскольку 
он входит в комплект загружаемого кода для этой книги. Не следует также беспокоить- 
ся, если вы не знакомы с СЫГ (интерфейс графических устройств в .МЕТ, предоставляю- 
щий объекты В1 тар, Еопф и тп.), так как в рассматриваемом примере это не главное. 


ро611с с1азз СаресваТпадеСопеко11ех : Сопеко11ек 
{ 
реахаее сопз® 10 ТпадемтаеВ = 200, ТиадеНел9ве = 70; 
рефуаее сопз® зЕк1па ЕопЕЕаш1Ту = "Воские! 1"; 
ркууаеке кеадор1у з6аф1с ВгазВ Еогедгоцра = Вгизвез .Мауу; 
рк1уате геадоп1у зв аё1с Со1ог Васкдкочпа = Со1ог.511уег; 
риб11с уо1а Вепаек (52109 сва11епдеби1а) 
{ 
// Извлечь текст решения из Зезз1оп [] 
зЕг1пс Кеу = СарбсваНе1рег.5езз1опКеуРхе{Е1х + сра11епдеби1а; 
ЗЕт109 зо1аЕ1оп = (836х119) НЕЕрСореех® .5езз1оп [кеу]; 
1Е (зоТабфой != пи11) [ 
// Создать пустое полотно для отображения на нем САРТСНА 
из1па (В1Етар Ютр = пем В1 тар (Тпадем19ЕЪ, ТтадеНе19ве)) 
15109 (СгарЬ1сз д = СкарЬ1сз .РкготТтасде (ртр) ) 
13109 (Копё ЕопЕ = пем Роп® (Еоосгаи1Ту, 1Е)) { 
с.С1еахг (Васкакочп9) ; 
// Выполнить пробную визуализацию для определения наилучшего размера шрифта 
ЭЗа2еЕ ЁЕ1па151=е; 
$1теЕ ЕезЕ51те = 9.Меазигебх109 (5оТаЕ1оп, Еою®); 
Е1оаЕ Безегопсб1хе = Мась .Мто (Тмадей1аеЬ / везЕ51хе.Изафеь, 
ТпасдеНезове / сезЕ512е.Незове) * 0.95Е; 
из1иа (РопЕ Е1па1РопЕ = пем РопЕ (ЕопЕЕап1Ту, БезеРопе51те)) { 
Е1па151=е = 9.Меазигеб®г1п9 (зоТа61оп, Е1па1Еоп®е); 
} 
// получить путь, который представляет текст, центрированный на полотне 
а.РадеЦп1® = СкарЬ1с80016.Ро1пе; 
РО1ОЕЕ КехЕТорьеЕЕ = пем Роз Е ( (ТтадемааеВ - Е1па1512е.И1аЕВ) /2, 
(ТпаденезоЪе - Е1па1$12е.Не1ой®) / 2); 
113119 (Скарб1сзРаеь раеВ = пем СгарЬ1сзРа®В()) { 
раев.Аад$ег1 по (зо1аЕ1оп, пем ЕопеЕап1Ту (гопекап1Ту), 0, 
БезЕРопЕ$1те, ЕехЕТорЬеЕе, бех1идкогкта®.Сбепег1с[еЕац1®); 
// Визуализировать путь в битовый образ 
9. ЗтооЕР1паМоде = бшоосБ1и9Моае .Н19Ъ0ца11%у; 
9.Е111Рабь (гохедкоцпа, ра®В); 


9. ЕТаЗЬ (); 
// Отправить изображение в поток ответа в формате СТЕ 
Везропзе.СоптепеТуре = "1таде/91Е"; 


Ыпр.бахе (Везропзе .ОцЕриЕ5Егеаш, ТтадеРоктас.С1Е); 
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Для того чтобы это скомпилировалось, понадобится импортировать ряд пространств 
имен, относящихся к СЬГ!. Просто установите курсор на любое нераспознанное имя 
класса и нажмите <С4+.>; все остальное сделает \1зиа1 Заало. 

Теперь, имея реализацию контроллера СарЕсваТмадеСопего11ех, можно перезагру- 
зить ОКЕ /Кед1зЕгаф1оп и увидеть изображение САРТСНА, как показано на рис. 11.13. 
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Искажение текста 


Все выглядит неплохо, но кое-чего не хватает. Этот текст способна распознать 
даже самая примитивная система ОВС. Существуют разные стратегии для Затрудне- 
ния автоматического распознавания, вроде искажения символов или наложения слу- 
чайных линий и узоров. Давайте и мы немного исказим картинку. Добавьте в класс 
СарЕсваТшадеСопего11ех следующий код: 


ре1уафе сопзЕ 116 МагрЕаског = 5; 
рге1уасе сопз® БочБ1е хАпр = МатрЕасеог * Ттадемтафь / 100; 
ргефуаее сопзЕ Роцр1е уАпр = иагрЕаског * Тиаденелойе / 85; 
ре1уасе сопзЕ Рочр1е хЕРкед = 2 * МафВ.РТ / Тпадемтаеь; 
ре1уафсе сопзЕ РоцЬ1е уЁЕкеа = 2 * МафВ.РГ / ТиадеНне1ове; 
рг1уаее Скарп1сзРаЕВ РеЕогпРа®В (СкарЬ1сзРаЕн рае№) 
{ 
Ро1рЕЕ[] деЕогмеЯ = пей Розп ЕЕ [рафЬ .РаеВРо1 пез .Тепо®Ь]; 
Вапдом гпд = пеи Вапаом(); 
РоцбТе хбеед = тпд .МехероцЮ1е() * 2 * МафЬ.РТ; 
Роир1е убееЯ = гпу.МехЕБоцЬ1е() * 2 * Маер.РТ; 
Бог (ЕЕ = 0 < расй .РаВРо1пЕ$.ТепаеН; 1++) 
{ 
РО1ПЕР от191па1 = рак .РаИРо1пе$[1]; 
Ропр1е уа1 = хЕгеа * ог191па1.х + уЕтеч * отг191па1.У; 
106 хоЕЁЕзее = (106) (хАшр * МабВ.51п (уа1 + х5еед)); 
106 УОЕЁЕзее = (116) (уАшр * МаЕн. $1 п (уа1 + уЗеед) ); 
ЧеЁЕогмеЯ[1] = пем Ро1пЕР (0ох191па1.х + хОЕЕзее, ог191па1.Х + уОЕЕзее); 
} 
терахп пем Сгарб1сзРафь (ЧеЕотгпеа, раеВ.РаеВТурез); 
} 


По существу, зтот код растягивает полотно на бугорчатой поверхности, определен- 
ной произвольными синусоидами. Полученная защита не является особо сложной, но 
при желании метод РеЕогиРаЕн () можно расптирить. Чтобы добавленный код дал зф- 
фекк измените строку кода в методе Кепаек() контроллера СареспаТтадесопетко11ег. 
которая отвечает за рисование текста, чтобы она вызвала реотшРа{! () (строка выде- 
лена полужирным): 
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// Визуализировать путь к битовой карте 
д.зпооЕр109Моае = ЗтооеЬ1п9Моае .Н1900па13%у; 
9.Е111РаЕЪ (Еогедгопп@, РебогмРафВ (ра®П)); 
9.Е1а3В {); 


Теперь экран регистрации выглядит так, как показано на рис. 11.14. 
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Верификация отправленной формы 


Итак, теперь имеется возможность выводить убедительно выглядящее изображение 
САРТСНА, но пока еще ничего не сделано в отношении верификации отправленных 
форм. Начните с реализации метода Уехг1 ЕуАпПдЕхр1гебо1а1оп () в СаресваНе1рех: 


ру611с зфаЕ1с БооТ Уег1ЕуАпаЕхр1тебо1а топ (НЕЕрСопфехЕВазе сопфех®, 
зЕт3па сва11епдеби1а, 
5 г1иа абфешрЕеЯ5о1а1оп) 


// Немедленно удалить решение из 5е5$1оп[] для предотвращения атак повторением 
зЕгтпа зоТаЕ1оп = (3611109) сопбехе .Зезз1оп [Зезз1опКеуРгеЕ1х + сва11епдеСо1а]; 
соптехе .5езз1оп.Ветоуе (53езз1опКеуРгеЕ1х + сра11епдебо1а); 

тебсоги ((зоТаблоп != 0011) && (абфетрееабо1ае1от == зо]1ае1оп))}; 


} 


Как объяснялось в начале рассматриваемого примера, код проверяет введенное поль- 
зователем решение на соответствие решению, сохраненному для заданного СИТО вызо- 
ва. Независимо от того, обнаружено ли соответствие, решение удаляется из 5еззтолт [1], 
препятствуя атакам повторным использованием известных решений. 

Теперь модифицируем метод действия ЗоБи1КедатзегаЕ1от() контроллера 
Вед1зЕ ха 1опСопего11ех для использования Уег1ЕуАпаЕхр1гебо1 11 (): 


рую11с АсЕ1опВезо1е биби1 Вече гхаЕ1оп (3&г1лпда шуСаресрва, зЕх1па аЕфетрь) 
{ 
1Е (СаресваНе1рег.\Уех1ЕуАпдЕхракебо1ае1 опт (НЕЕрСопеехе, шуСаресра, абфетру)) 
{ 
// В реальном приложении действительно зарегистрировать пользователя 
гефока Сопфеп® ("Разз"); 
} 
е1 зе 
{ 
// В реальном приложении повторно отобразить представление с сообщением об ошибке 
тебиха Сопеей® ("Га11"); 


} 
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Вот и все. Если посетитель введет корректные буквы, метод отобразит сообщение 
Раз5 (Пройдено), а в противном случае — Ра11 (Не пройдено). В качестве альтернативы 
можно изменить логику так, чтобы в случае непрохождения теста САРТСНА сообщение 
об ошибке направлялось в Моде1 5 ате и затем заново отображалось то же самое пред- 
ставление регистрации. 

В заключение следует отметить, что создать вспомогательный метод САРТСНА, ко- 
торый легко повторно использовать во множестве форм по всему приложению АЗРМЕТ 
МУС, очень просто. Рассмотренный выше пример не защитит от наиболее настойчи- 


вых взломщиков, хотя, впрочем, для этого вряд ли будет достаточно одного лишь теста 
САРТСНА. 


Совет. Для того чтобы превратить приведенную выше логику верификации в многократно исполь- 
зуемый, распространяемый компонент САРТСНА для применения во многих решениях, достаточ- 
но поместить классы СареспаНне1рег и СаресаТпадеСовпего11ех в отельную сборку. 


Ссылки подтверждения и защита 
от искажения с помощью кодов НМАС 


При разработке веб-приложений возникают две распространенных ситуации. 


® Необходимо отправить посетителю ссылку по электронной почте, сопроводив тек- 
стом вроде “Щелкните сюда, чтобы изменить забытый пароль", но реализовать 
это, разумеется, не в виде ОБГ /Озегз/СвапдерРаззиоха?ИзегтТ0=1234, потому 
что злонамеренный или любопытный посетитель сможет легко заменить иденти- 
фикатор пользователя 1234 каким-нибудь другим. 


® Требуется сохранить некоторые данные о состоянии в скрытом поле НТМ!- 
формы и каким-то образом гарантировать, что они не будут отредактированы 
злоумышленником. 


В любом случае необходим способ получить строку (например, 1234 в первой ситуа- 
ции} и проверить, что она была выдана вашим сервером и не подвергалась изменениям. 
Может даже нужно убедиться, что она была выдана недавно, если срок ее пригодности 
составляет, скажем, 24 часа. 

Одна из возможных стратегий состоит в том, чтобы создать таблицу базы данных 
со столбцами Си1а, Зесогедраха и Ехр1хура‹е. Вместо отправки клиенту данные по- 
мещаются в таблицу, а взамен их посылается значение бо194. Такой подход работает, 
но использование базы данных при этом не слишком удобно. В сценарии с высокой 
нагрузкой в базе одновременно могут оказаться миллионы фрагментов секретных дан- 
ных, и в любом случае придется установить какие-то расписания для периодической 
очистки устаревших данных. 


Служебный класс НМАС 


Более злегантное и предпочтительное решение предусматривает использование хепт- 
кода проверки подлинности сообщения (Ваз тб теззаяе аПепНсаНоп сое — НМАС). 
Это не подразумевает хранение каких-либо данных на сервере, однако обеспечивает 
криптографическую защиту от нежелательного вмептательства. 

Каким образом это работает? Техника НМАС основана на применении алгоритма 
хеширования, который генерирует из произвольных входных данных короткий, уни- 
кальный хеигкод. В алгоритме используется секретный ключ, который позволяет вы- 
числить конкретный хет-код для определенного ввода только обладателю этого ключа. 
Ниже кратко описано решение с хеш-кодом. 
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® Сначала пользователю передается некоторое уязвимое значение (например, иден- 
тификатор пользователя в скрытом поле формы}, а также хеш-код этого значе- 
ния (в отдельном скрытом поле формы). 


® Когда пользователь отправит уязвимые данные обратно, будут получены и важные 
данные, и их хепт-код. Это позволяет повторно вычислить хеш-код для отправленных 
данных и сравнить его с отправленным хепгкодом. Пользователь не сможет вмешать- 
ся в важные данные, потому что если он это сделает, хеш-код перестанет им соответ- 
ствовать (алгоритм вычисления хеш-код известен только тому, кто его реализовал). 


Хотя это блестяще работает в теории, на практике следует остерегаться различных 
лазеек. Например, не хешируйте просто значение 1п%, потому что как только хакер 
узнает хеш-код для определенного целочисленного значения, он сможет повторно ис- 
пользовать его в другой части приложения, где тоже хешируются целые числа. Чтобы 
предотвратить это, добавляйте во входные данные произвольную строку. уникальную 
для контекста, в котором предполагается использование хеша. Кроме того, для гене- 
рируемых хеш-кодов имеет смысл предусмотреть автоматическое устаревание, чтобы 
ограничить ушерб, если хакер завладеет хеш-кодом для чужого значения (например, 
используя атаку Х$5}. 


На заметку! Почему следует предотвращать искажение данных с помощью кодов НМАС, а не вос- 
пользоваться шифрованием? Дело в том, что криптография — вещь сложная, и обеспечить га- 
рантию того, что данные находятся в безопасности, могут разве что эксперты в этой области. 
Техника НМАС специально спроектирована для сертификации источника данных, а именно это и 
требуется. С другой стороны, обычное шифрование призвано решать другую задачу: оно прелот- 
вращает чтение данных внешними субъектами, но не обязательно препятствует вмешательству в 
них (злоумышленник может наугад изменить какой-нибудь бит, не будучи в состоянии предсказать 
результат, но он никогда не сможет непреднамеренно получить другое корректное значение). 


В следующем примере будет показано, как использовать АРГ-интерфейс „МЕТ 
ЕгатеуюгК Зузфет. Зесих1еу.Скуреодгарьу для генерации кодов НМАС. В коде приме- 
ра применяется класс по имени НМАСЗНА1, который генерирует хеш-коды по алгорит- 
му. производному от ЗНА1. Он помещен в оболочку служебного класса ТапрехРхооЁ1аа, 
который создает автоматически устаревающие хеш-коды, встраивая дату их истечения 
во входные данные. 


руЮ11с зфаё1с с1а5$ ТапрегРхооЕ1аа 
{ 
// В своем приложении измените Кеу на любые случайные 8 байт 
// и храните их в секрете 
зфае1с руЕе[] Кеу = пеи Бубе[] { 93, 101, 2, 239, 55, 0, 16, 188 }; 
руБ11с епиш НМАСВезо1е { ОК, Ехр1геа, Тихалла } 
рур11с зфаф1с зех1па бееЕхр1х1поНМАС (5ех411п9 шеззаде, РафеТ1ше ехр1хурафе) 
{ 
НМАС а19 = пем НМАСЗНА1 (Кеу); 
Фу { 
зЕг1па тароф = ехр1гурафе.Т1сК$ + пеззасде; 
рубе[] вазЬВусез = а19 .СотрофеНазЪ (Епсо41па.ОТЕ8 .СеЕВуфез (1про®)); 
БуЕе[}] гезо1е = пем Бубе[8 + ВазЪВуеез .ЁТепо\В]; 
ВазрВуфе$ .СоруТо (хезо1е, 8}; 
В1ЕСопуегеег.сСеЕВуфез (ехр1гурафе.Т1ск$) .СоруТо (тезо14, 0); 
тебокп 5иар (СопуегЕ.ТоВазеб 45+ тг1п9 (хези1), "+=/", "- ,"); 
} 
Е1па11у { а19.С1еах(); } 
} 
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ру611с зфаЕ1с НМАСВезо1Е Уег1ЁЕу (3Ет1п9 шеззаде, зЕг1лаа ехр1е1паНМАС} 

{ 
рубе[] Бубез = Сопуег®е .ЕхомВазе645Ех1п9 (5мар (ехрук1паНМАС, "- ,", "ч=/")); 
РафеТлме с1алиедЕхр1ку = пем РафеТ1ме (В1ЕСопуегеех.ТоТипт64 (руфез, 0)); 


1Е (сТалмедЕхраугу < РасеТлие Мом) 
гесиго НМАСВези1е.Ехрагеа; 
е1зе 1 (ехр1е1поаНМАС == себЕхр1г3поНМАС (шеззаде, с1а1теяЕхрагу) } 
геЕигп НМАСВези1е.0К; 
е1зе 
теЕихо НМАСВези1е.Тпуа11а; 
} 


рг1уаее экаф1с зЕх1пч 5иар (56 т1па зЕх, зЕгапа 1приЕ, зЕгапа опери®) { 
// Используется для исключения символов, которые небезопасны для ОВЬ 
Бог (10 1 = 0; 1 < 1проае.ТепаЕев; 1++) 
зЕг = з6г.ВерТасе (1проЁ [1], оперие[1]); 
тесагп $56г; 


} 


Внимание! Если вы решите воспользоваться классом ТапрехРхооЕ1па, обезопасьте приложе- 
ние, изменив содержимое массива Кеу другой секретной последовательностью произвольных 
байтов. Кроме того, не оставляйте никаких средств, с помощью которых внешний субъект смо- 
жет заставить приложение вычислить и вернуть код, НМАС для произвольного сообщения. 


Пример применения 


Служебный класс ТапрегРхооЕ1пд можно использовать в контроллере примерно так: 


рою11с с1азз РглхеС1алтСопеко11ек : Сопеёго11ек 
{ 
руЮ11с УлемВези1Е С1алиГохги () 
{ 
зЕх1по рглте = "$10.00"; 


РафеТлме ехр1гу = РафеТ1ме. Мом. АЗЯаМ1тиеез (15); 
тебаха Утем (рем { 
Рултейоп = ргл?е, 


Рг1хеНазВ = ТапрегРгооЕ1та.СееЕхрак1поНМАС (рг1ге, ехр1гу) 
}); 
} 


рУю11с эЕглид баба ЕС1али (56 г1па Рг1теИоп, зЕхлоа Рт1хеНазр, $+г10д Ааахе$з) 
{ 

уаг уег1Е1са&1опКеза1ф = ТапрегРгооЕ1та .Уег1Еу (Рг12емоп, Рг1теНаз|в); 

1Е (уег1Е1сае1опВези1Е == ТатрегРхооЕ1па .НМАСВези1%.0К) 


тебиги 56х1па.Гогшае (“ОК, ие’11 зепа ЕЪе {0} №о {1}", 


НЕЕрО&11 1 у. Неш1Епсоае (Рх17еМмоп), НЕЕРОЕ111 у. Не] Епсоде (АЗЯгезз)); 
е1зе 


гегикп "боггу, уой Ег1е@а со среаф ог меге оо 310ои."; // Или попытка 
// обмануть, или чрезмерная медлительность 


} 


Представление для действия С1а1щЕоги может иметь следующее содержимое: 
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<11>Сопдгаео1а 1015, уоп'уе моп <%= У1емБафа.Еуа1 ("Рхзтгеймоп") %>!</в1> 
<р>С1а1т 3 реЁоге 1Е ехр1хез.</р> 

$ 15119 (НЕш1.ВедаиКоги ("библ ЕС1а1т", "Ру1хеС1алщ")) { %> 

<$= НЕт1.Нлааеп ("Рх12еНазь")} %> 

<93у>Рт1те: <%= Не .ТехеВох ("Рг1темоп") %></алу> 

<@1у>Уопг аЯ99гез$: <%= Ни] .ТехфЕАгеа ("АЯгезз", по11, 4, 15, па11)} $%></а1у> 
<р а119п-"сепеех"><1приЕ суре="зоюи1е" уа1ие="Зиби1е рг1хе с1аф" /></р> 


< г г 8. Беру Лосатозь обои РнзеСант  ЧаитРогил 


| СопогайЦайоп$, уош'уе уоп $10.00! 


Сана # Беле Я ехраез. 


шли 


Риге: $10.00 


225 Му Бсхеес 


тли оао оф 


Если вы не изменяли значение 
в поле Риге (Выигрыш) 


Если вы изменили в поле Риге (Выигрыш} 
или прождали более 15 минут 


НЕ 
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| 
| 
й 
| 
| 


| коанный 


Рис. 11.15. Защита от искажения в действии 


Хранить значение Рх12еМоп где-то на сервере нет необходимости, так как оно сохра- 
няется в полностью видимом, редактируемом текстовом поле на стороне клиента*, и все 
же вы можете быть уверены, что пользователь не изменил значение. Также не придется 
нигде более сохранять дату срока годности, потому что она включается в хеш. 


Совет. Если служебный класс НМАС используется для защиты от искажения параметра строки 
запроса (например, рагап=1234), ссылку должна иметь вид "/0х1?рагап=1234&пазь=" 
+ ТапрегРгооЕ1п9 .СефЕхр1 г1поНМАС ("1234", ехр1гурате). Все символы, которые 
поступают из метода СесЕхрух1поНМАС () ‚ являются безопасными для ЦВЕ. 


* Это сделано только для целей демонстрации. В реальности такой подход, скорее всего, будет 
применяться для защиты скрытых полей форм. 
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Резюме 


В этой главе были продемонстрированы общие функциональные возможности веб- 
приложений и способы их реализации в АЗРМЕТ МУ.С. К ним относится проверка досто- 
верности, многошаговые формы (мастера), элементы САРТСНА и защита от искажения. 
Кроме того, вы узнали, как использовать привязку модели для приема и автоматическо- 
го разбора сложного пользовательского ввода. 

Поскольку вы уже ознакомились с болыпинством встроенных средств МУС ЕгатеуогК, 
в вашем распоряжении теперь есть болыпинство строительных блоков для создания ти- 
пичного веб-приложения. Однако пока еще не было уделено внимание интерактивно- 
сти клиентской стороны. В следующей главе будет показано, насколько хоропо АЗРМЕТ 
МУС работает с Чауазсирё и Адах, помогая создавать развитые и современные пользова- 
тельские интерфейсы для ваших клиентов. 


ГЛАВА 12 


А]ах и сценарии 
клиента 


ЗРМЕТ МУС — в первую очередь и по болыпей части технология серверной сторо- 
ны. Это исключительно гибкая среда для обработки НТТР-запросов и генерации 

ответов в виде НТМГ-разметки. Но сама по себе НТМГ-разметка статична — она обнов- 
ляется каждый раз, когда браузер загружает новую страницу, а потому не может обеспе- 
чить интерактивное взаимодействие с пользователем. Чтобы манипулировать объект- 
ной моделью документа (аоситеп оЩес{ пзоде! — РОМ} непосредственно в браузере или 
нарушить традиционный полностраничный цикл запросов-ответов, нужна программ- 
ная технология, которая работает внутри браузера (те. на стороне клиента). 

Недостатка в технологиях клиентской стороны никогда не испытывалось. В распо- 
ряжении разработчиков есть Зауа$ ср, НазВ, УВспрё, АсйуеХ, аплеты Зауа, файлы 
НТС, ХШ, а теперь еще и ЭЙуег15Ъ. Фактически имеется настолько много несовмес- 
тимых технологий, каждая из которых может быть как доступна, так и не доступна в 
конкретном браузере посетителя, что многие годы ситуация оставалась неизменной. 
Болышнинство веб-разработчиков перестраховываются и предпочитают вообще не поль- 
зоваться языками сценариев клиентской стороны, несмотря на то, что чистая НТМГ- 
разметка выглядит очень бедно по сравнению с интерфейсами настольных приложений 
(Упао\з Еогил$ или МРЕ). 

Потому и не удивительно, что веб-приложения заслужили репутацию медлительных 
и неудобных. Но начиная с 2004 г., появилась целая серия высококачественных веб- 
приложений, включая Ста! от Соофе, которые интенсивно использовали Зауа сре для 
создания впечатляюще быстрых пользовательских интерфейсов, подобных настольным 
приложениям. Эти приложения могут быстро реагировать на пользовательский ввод, 
обновляя небольшие подразделы страницы (вместо загрузки нового документа НТМЕ, це- 
ликом). Для этого использовалась технология, получившая название Алах'. Практически 
в одночасье веб-разработчики по всему миру поняли, что Чауа си! ре — мощное и (почти 
всегда) безопасное в применении средство. 


' Аббревиатура Аах означает азупсйгопои$ Чаразспре апа ХМЕ, (асинхронный УахаЗспре 
и ХМГ.. В настоящее время лишь немногие веб-приложения передают данные в формате 
ХМГ — обычно используются форматы НТМЕ, или ЗЗОМ, — но применяемую технологию все 
равно называют Афах. 
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Причины использования инструментальных 
средств Чауа$ сир: 


Если бы на этом закончились все сложности! Недостаток ДауаЗсйре состоит в том, 
что каждый браузер по-прежнему предлагает слегка отничающийся АР!-интерфейс. 
Кроме того, будучи действительным языком динамического программирования, 
ЧахазсПр{ обескураживает программистов на С#, которые привыкли думать в терминах 
типов объектов и ожидают полной поддержки средства П\еШЗепзе. 

В основном применение ЗауаЗсир{ и Адах требует приложения немалых усилий. 
Для облегчения этой ноши можно воспользоваться инструментальными средствами 
Чауа5сйре от независимых поставщиков, такими как }Оцегу, Ргобобуре, МооТоо]$ или 
Всо, которые предлагают простой уровень абстракции для решения распространенных 
задач (например, асинхронных частичных обновлений страницы), не погружаясь в де- 
тали. Из перечисленных ]Фчегу заслужил репутацию самого замечательного подарка 
для веб-разработчиков, настолько удачного. что даже Мсгозой. теперь поставляет его 
вместе с АЗРМЕТ МУС и собирается включить в будущие версии \У15ца! Эва а1о. 

Некоторые разработчики АЗРМЕТ не уловили наметившуюся тенденцию и по-преж- 
нему избегают применения инструментов ЗауаЗспри или даже самого языка Зауасирё. 
Во многих случаях это объясняется чрезвычайно сложной интеграцией традицион- 
ных приложений У\еБЮКогил$ с библиотеками Чауаспри от независимых поставщиков. 
Технология обратных отправок на платформе \МеБЕогилз, ее изощренная модель событий 
и элементов управления серверной стороны, а также склонность управлять идентифика- 
торами элементов — вместе все это вызывает затруднения с использованием Зауа стра. 
В Мсгозой нашли решение, выпустив собственную \\МеБЕоги1з-ориентированную биб- 
лиотеку Чауа5с"реё — АЗРМЕТ АдАХ. 

На платформе АЗРМЕТ МУС все эти сложности просто не существуют, так что в рав- 
ной степени можно пользоваться любой библиотекой ЗауаЗспрь в том числе и АЗРМЕТ 
АЧАХ. Возможные варианты выбора технологий представлены на рис. 12.1. 

В первой половине этой главы вы узнаете. как использовать встроенные в АЗРМЕТ 
МУС вспомогательные методы Азах.*, которые имеют дело с простыми сценариями 
применения Адах. Во второй половине главы будет показано, как использовать }Очегу с 
АЗРМЕТ МУС для построения сложного поведения, сохраняя поддержку и для меньшин- 
ства посетителей, браузеры которых не могут выполнять код Чауа сре. 


Вспомогательные методы 
АЗР.МЕТ МУС Азах.* 


Другая платформа Зама$сире 
(например, Ргок\уре) 


Низкоуровневый код Зауабсйре 


АР!-интерфейс текущего браузера 


ь Юиегу 
М {1 АЗР. 
ООВ ГАНЫ (входит в состав АЗР.МЕТ МУС} 


Рис. 12.1. Варианты выбора технологий для Аах и клиентских сценариев в АЗРМЕТ М\УС 


Глава 12. фах и сценарии клиента 409 


Вспомогательные методы АзЗах .* в АЗР.МЕТ МУС 


МУС ЕгатехюогК поставляется с набором вспомогательных методов Адах.*, которые 
существенно упрощают организацию частичного асинхронного обновления страниц. 


® А]лах.АсстопГлок() визуализирует дескриптор ссылки аналогично методу НЕт1. 
АСЕТОПГ1ЮК(). При щелчке на этой ссылке производится извлечение и вставка 
нового содержимого в существующую НТМГ-страницу. 


® А)ах.ВеолпЕоги() визуализирует НТМГ.-форму аналогично методу Нет] .ВедзпЕокл (). 
При отправке этой формы производится извлечение и вставка нового содержимо- 
го в существующую НТМГ-страницу. 


® А)]ах.Вопсеглек() подобен методу А}фах.АселорГ1тКк() за исключением того, что 
он генерирует ОРТ, из произвольного набора параметров маршрутизации, не обя- 
зательно включая параметр действия асЕ1 оп. Это Адах-эквивалент вспомогатель- 
ного метода Неп1.Воиеер1иКк(). Он наиболее удобен в расширенных сценариях, 
при обращении к специальной реализации интерфейса ТСопЕго11ех, которая 
может не поддерживать концепцию метода действия. В остальном применение 
Азах.Воосерлик() идентично А]ах.АсетопЬтак (). 


® А]ах.Ведтокоцфегоги() подобен методу Азах.Вед1пРГоги() за исключением того, 
что он генерирует ОВ! из произвольного набора параметров маршрутизации, не 
обязательно включая параметр действия асе1оп. Это Азах-эквивалент вспомога- 
тельного метода НЕм1 .Вед1пВонееКоги(). В остальном его применение идентично 
А]ах.Вед1иВонееКогиа(). 


Перечисленные методы .МЕТ представляют собой оболочки вокруг функционально- 
сти библиотеки М1сгозой АЗРМЕТ АЗАХ, поэтому они будут работать в большинстве со- 
временных браузеров? при включенной поддержке Лауа$сир(. Вспомогательные методы 
просто избавляют от необходимости написания кода ЗауаЗспре и знания библиотеки 
АЗРМЕТ АЗАХ. 

Обратите внимание, что страницы представлений имеют доступ к свойству по 
имени Адах типа ЗузЕет.Мер.Мус.АзахНе1рег. Вспомогательные методы, подобные 
АсЕтопЬзоК(), не определены непосредственно в А]ахНе1рег: на самом деле они явля- 
ются расширяющими методами для этого типа. Эти расппиряющие методы в действи- 
тельности определены и реализованы в статическом типе по имени А] ахЕхееп51оп$ в 
пространстве имен ЗузЕет.Мер.Мус.А}ах, что позволяет добавлять собственные спе- 
циальные вспомогательные методы Адах.* (просто определяя новые расширяющие 
методы в А}захНе1рег). Можно даже полностью заменить встроенные методы, удалив в 
иеф.сопЕ19 ссылку на ЗузЕет.ИМеф.Мус.Азах. В общем, все делается точно так же. как 
при добавлении или замене вспомогательных методов Нем] .*. 


Асинхронная выборка содержимого страницы 
с использованием метода А]ах.АсЕтопТ лок 


Чтобы можно было пользоваться описанными выше вспомогательными методами, в 
НТМЕ-страницы потребуется добавить ссылки на два файла Чауа сре. Один из них со- 
держит реализации вспомогательных методов АЗРМЕТ МУС Азах. *, а второй — библио- 
теку АЗРМЕТ АЗАХ, на которую эти реализации полагаются. Оба файла по умолчанию 
находятся в папке /5сг1рез каждого нового проекта АЗРМЕТ МУС, но на них нужно 


2 В их число входят НабегпеЕ Ехр|огег 6.0, Етеюх 1.5, Орега 9.0, За! 2.0 и последующие вер- 
сии этих браузеров. 


410 Часть |. АЗРМЕТ МУС во всех деталях 


установить ссылки, добавив дескрипторы <зсг1рЕ> в начало раздела <Ъеаа> представ- 
ления или мастер-страницы: 
<рЕи1> 
<пеа@ гхипаф="зетгуег"> 
<зсхуаре зхс="<%= Ог1.Сопфеп* ("-/$сгарез/М1сгозоЕЕАзах.З5") %>" 
фуре="Еех*/3ауазсхк1ре"></зск1р®> 
<зсг1ре згс="<%= Ог1.Сопеп® ("^/5$сх1рез/М1сгозоЕЕМусАдах.]з") %>" 
фуре="+ехе/3ауазск1ре"></зскарЕ> 
<!-- Остальное без изменений --> 
</Веа9> 


</вЕи1> 


Совет. При обращении к файлам амаЗсир{ используйте метод 0х1 .Сопееп® () вместо жестко- 
го кодирования абсолютного ЦВЕ. Это позволит дескрипторам сохранить работоспособность 
даже после развертывания в виртуальном каталоге. 


Вспомогательный метод Азах.АсетопЬаик () подробно рассматривается далее в гла- 


ве. Но сначала давайте посмотрим на него в действии. Пусть имеется следующий фраг- 
мент шаблона представления: 


<в2>\Таф Елще 15$ 162?</62> 


<р> 
5Вои ше ЕБе Елще 11: 
%$= А]ах.Асе1оп1ак ("ОТС", "бееТАие", пем { хопе = "абс" }, 
рем А] ахОрЕ1оп5$ { ОрдафеТагдееТА = "туВези1+з" })} %> 
<%= Адзах.АсЕтоптлиКк("В5Т", "бесТ1те", пем { гопе = "Бе" }, 
рем А] ахОрЕ1оп5 { ОраасеТагдеЕТа = "туВезо1ез" }) %> 
<$= А]ах.Аселоптлик ("МОТ", "СефТ1ие", пеи { хопе = "маф" }, 
рем А] ахОрЕ1оп5 { ОрдафеТагдеета = "шуВези145" }) %> 
</р> 


<а1у 19="туВези1е5" 5у1е="Бох@ех: 2рх аосфеа геб; раЯ91п9: „.5еш;"> 
Везо1е5 и111 арреаг Веге 

</91> 

<р> 

ТрЬ15 раде маз депегафеа аё <%= РафеТ1те.ОесМом.Тобехлиоа ("В:ММ:з8 Е") > (0ТС) 

</р> 


Каждая из трех ссылок Адах запраптивает данные из действия беетуте (на текущем 
контроллере}, передавая ему параметр по имени гопе. Ссылки встраивают ответ от сер- 
вера в элемент @1у по имени муВезо1+3, заменяя его прежнее содержимое. 

Сейчас щелчки на этих ссылках не дают какого-либо эффекта. Браузер выдаст асин- 
хронный запрос, но пока еще нет никаких действий по имени сееТ1те, поэтому сервер 
отреагирует опгибкой “404. Мо Еоипа” (не найдено). Тем не менее, сообщение об оптибке 
не отобразится, потому что вспомогательные методы АЗ ах. * не выдают никаких сооб- 
щений об ошибках, если им явно не указано делать это. Давайте заставим их работать, 
реализовав метод сееТ1те (), как показано ниже: 

`ру611с зЕг1п9а СееТ1ие (5&г1п9 хопе} 
{ 
РафеТ1те Е1ще = РабеТ1ме. ОесМом. АЧЧНочгз (оЕЁЕзеез [хопе]}; 
гегагп зех1па.Когиаф ("<91у>Тре Е1ме 1 {0} 13 {1:В:ММ:зз ЕЕ} </алу>" $ 
2оре.То0ррег(), Е1те); 

} 

рг1уафсе Р1с®1опагу<5Ег1па, 1пе> оЕЁзеёз = пем Рас 1опагу<8вЕ гта, 1пе> { 

{ "цесс", 0 }, { "Зе", 1}, { "пас", -6 } 

}; 
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В этом методе действия нет ничего особенного. Ему не нужно знать или заботиться 
о том, что он работает как асинхронный запрос — это просто обычный метод действия. 
Если поместить точку останова внутрь метода бееТ1те() и затем запустить приложе- 
ния в отладчике \1зиа1 За, легко заметить, что СееТ1пе () вызывается (для обработ- 
ки асинхронного запроса) в точности так же, как любой другой метод действия. 

Для простоты этот метод действия возвращает простую строку. Но с тем же успе- 
хом он может визуализировать частичное представление или делать что-то еще, что в 
результате отправит текст обратно в браузер. Что бы ни отправлялось обратно из этого 
метода действий, ссылки, сгенерированные методом Адах.Асе1опЬ1пК (), вставят это в 
текущую страницу, как показано на рис. 12.2. 
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Рис. 12.2, Метод Адах.АсЕ1топ11 ик () обеспечивает вставку ответа в злемент ВОМ 


Как видите. все просто! Обратите внимание, что хост-страница остается постоян- 
ной — метка времени внизу не изменилась. Было предпринято частичное обновление 
страницы, что и является основной изюминкой Дах. 


Внимание! Если в браузере отключена поддержка ЧамаЗсир\, то эти ссылки будут вести себя по- 
добно обычным ссылкам, сгенерированным с помощью метода Нкт1 .АсЕ1опЬ1тК(). Это 
значит, что вся страница будет заменена ответом сервера, как при традиционной веб-нави- 
гации. Иногда такое поведение является именно тем, что нужно, но чаще зто не так. Далее 
в зтой главе будут показаны примеры применения подхода, называемого последовательным 
расширением, который позволит сохранить удовлетворительное поведение приложения даже 
при отключенном УамаЗсиру. 
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Передача параметра А}ахОр1опз методу А]ах. АсЕтопТ1 ок 


Метод А)ах.АсЕтопТ1тк() имеет множество перегрузок. Большинство из них соот- 
ветствуют различным перегрузкам НЕп1 .АсетопГапк (), поскольку разные комбинации 
параметров просто обеспечивают различные способы генерации целевых ОВ, из па- 
раметров маршрутизации. Основное отличие этого метода связано с необходимостью 
передачи параметра типа А} ахОрЕ1оптз, который позволяет конфигурировать желаемое 
поведение асинхронной ссылки. Доступные свойства перечислены в табл. 12.1. 


Таблица 12.1. Свойства класса АзахОрЕ1оп5 


Свойство Тип Назначение 


СопЕ1 кт ЗЕЕ1па Если указано, в браузере откроется окно с вашим 
сообщением и кнопками ОК и Сапсе! (Отмена). 
Асинхронный запрос будет выдан, только в случае щелч- 
ка на ОК. Большинство разработчиков используют это 
окно для вывода вопроса вроде “Вы действительно хо- 
тите удалить запись [имя]?” (что не совсем правильно, 
поскольку кнопки ОК и Сапсе[не совсем подходят для 
ответа на такой вопрос}*. 


НЕЕрМесвоа ЗЕЕАиа Указывает, какой метод НТТР (те. СЕТ или РОЗТ) должен 
использовать асинхронный запрос. Вы не ограничены 
только методами СЕТ и РО$Т. Можно также применять 
и другие методы, вроде РТ или РЕГЕТЕ, если вы пола- 
гаете, что они описывают операцию более осмысленно. 
(Теоретически есть возможность даже создавать собст- 
венные имена методов, хотя вряд ли это понадобится.) 


ТпзекезопМоае ТизекЕ1опМоае Указывает, следует ли заменить существующее содер- 
{перечисление} — жимое целевого элемента (по умолчанию — заменить} 

или же добавить новое содержимое перед элементом 

(ТпзекЕВеЕоге) либо после него (ТизекЕАЕКек). 


Тоа91паЕ1етепеТА  з®к1па Если указано, то НТМЕ-злемент с этим идентифика- 
тором будет сделан видимым (через С5$5-правило 
наподобие 91 зр1ау:Б1Тоск, в зависимости от типа 
элемента), когда асинхронный запрос начнется, а за- 
тем скрыт (используя 41 зр1Тау: попе), когда запрос 
завершится. Чтобы отобразить индикатор выполнения 
загрузки, на мастер-страницу можно поместить ани- 
мированный @Е, изначально скрытый с помощью С$$- 
правила а1 зр1ау: попе, а затем сослаться на его 
идентификатор через цоа91пчЕ1етере Та. 


ОпВед1п ЗЕг1п9 Имя уама$сир-функции, которая будет вызвана непо- 
средственно перед началом асинхронного запроса. Для 
отмены асинхронного запроса необходимо вернуть зна- 
чение Га1 зе. Более подробные сведения будут даны 
ниже. 


ОпсошрТеке ЗЕЕ1п9 Имя Чауа$сир-функции, которая будет вызвана по 
завершении асинхронного запроса, независимо от его 
успеха или неудачи. Более подробные сведения будут 
даны ниже. 
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Окончание табл. 12.1 


Свойство Тип Назначение 


Оп5иссе$5 зЕг1па Имя ЧамаЗсйр-функции, которая будет вызвана, если 
асинхронный запрос завершился успешно. Это проис- 
ходит после ОпСопр1Т еее. Более подробные сведения 
будут даны ниже. 


ОпЕа11иге ЗЕк1 па Имя Чамабсир!-функции, которая будет вызвана, если 
асинхронный запрос завершится неудачно (например, 
сервер вернет код состояния 404 или 405). Это случится 
после ОпСотр1Т еее. Более подробные сведения будут 


даны ниже. 

ОрдаееТакаеетТа ЗЕг1та Идентификатор НТМ!-злемента, в который необходимо 
(обязательное) вставить ответ сервера. 

Ч к1 ЗЕг1иа Если указано, асинхронный запрос будет передаваться 


по этому УР, переопределяя ЦВЕ, сгенерированный 
из параметров маршрутизации. Это дает возможность 
обращаться к различным ЦВЕ, в зависимости от того, 
включена ли поддержка /ауабсирЕ (если не включена, 
то ссылка работает подобно обычной НТМЕ-ссылке на 
УВЕ, сгенерированный из указанных параметров мар- 
шрутизации). Обратите внимание, что из соображений 
безопасности браузеры не разрешают перекрестные 
запросы Арх, поэтому можно обращаться только к ВЕ 
из текущего домена приложения. 


* Встречалось также веб-приложение, в котором выводилось окно с вопросом типа: “Вы действительно 
хотите отменить это задание? ОК/СапсеГ. К сожалению, простого способа отобразить приглашение с 
вариантами ответов, отличных от ОК и Сапсер, не существует. Это ограничение, накладываемое самим 
браузером. 


Запуск Чаиа$спре-функций перед или после асинхронных запросов 


Свойства ОпВед1п, ОпСошр1ете, Опбиссезз$ и Опга11иаге можно использовать для вме- 
гтательства в различные точки асинхронного запроса. Последовательность их запуска 
такова: ОпВед1п, затем ОпСотр1еее и, наконец, либо Опбиссезз, либо Опга11иге. Эту по- 
следовательность можно прервать, вернув значение Еа1зе из ОпВед1п или Опсошр1есе. 
В случае возврата другого значения (или вообще никакого) оно просто игнорируется. а 
последовательность продолжается. 

Любая из этих четырех функций при вызове получает единственный параметр, опи- 
сывающий все, что происходит Например, для вывода сообщения об оптибке можно на- 
писать следующий код: 


<зсЕ1рЕ суре="ЕехЕ/)ауазсуи1ре"> 
Еопсефой Бапа1ТеЕгког (а) ахСопеехе) { 
уаг гезропзе = а]лахСопеех®.чее гезропзе(); 
уаг зЕатозСоае = гезроп5е.чее зкабизСоае (); 
а1ег+ ("боггу, ЕБе гедаезЕ Еа11Теа м1ЕБ зЕабаз сое " + зфасазСоае); 


} 
</зсгарЕ> 
<$= А]ах.АсеторпГ1 пк ("С11ск пе", "МуАсЕтоп", 
пеи А)лахОрелопз { ОрдасеТатдеста = "шуЕ1етепе", ОпЕа11иахе = "Вапо1еЕкгог"}) %> 
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Параметр а} ахСопЕехе представляет функции, перечисленные в табл. 12.2, которые 
можно использовать для извлечения дополнительной информации о контексте асин- 
хронного запроса. 


Таблица 12.2. Функции параметра азахСопеех*, передаваемого обработчикам 
ОпВед1п, ОпСопр1ефе, ОпЗиссез$ и ОпЕа11тте 


Метод Возвращаемое значение Тип возвращаемого значения 
дес Чака () Полная НТМ!-разметка для ответа серве- Строка. 
ра (следующего за успешным запросом). 
дее_1п5ег%Моае () Значение перечисления 0, 1 или 2 (означает со- 
ТипзекЕтопМоде, использован- ответственно КерТасе, 
ное для данного вызова метода ТизегЕВеЕоге или 
А)ах.Асезоп1 ик (). ТизекЕАЕЕег). 
че Лоад1идЕЛетейЕ ()  НТМЕ-элемент, соответствующий иден- Элемент ООМ. 
тификатору гоа91пчЕ1емепета. 
дее_ геацез* () Исходящий запрос. Тип Зуз .Меф.Иервечиезе 
из АЗРМЕТ АУАХ (см. докумен- 
тацию по АЗР МЕТ А.АХ). 
деЕ гезропзе () Ответ сервера. Тип буз.Мек. 


МерВеаае Е хеси®ог из 
АЗРМЕТ АААХ (см. документа- 
цию по АЗР МЕТ ААХ). 


деЕ ирааЕеТакгсдек () НТМЕ-элемент, соответствующий иден- Элемент ООМ. 
тификатору ОрдакеТагдее Та. 


Обнаружение асинхронного запроса 


Как упоминалось ранее, Адах.АсетопЬтик () может извлечь НТМТ.-разметку из любо- 
го метода действия, и методу действия не обязательно знать, что он обслуживает асин- 
хронный запрос. Это верно, но иногда важно знать, обрабатывается асинхронный за- 
прос или обычный. Соответствующий пример будет приведен далее в этой главе, когда 
мы займемся сокращением пропускной способности, потребляемой запросами Дах. 

К счастью, это легко определить, потому что каждый раз, когда М1скозоЕЕМусАзах. 95 
выдает асинхронный запрос, он добавляет специальный параметр запроса Х-Ведаезеа-"НЕВ 
со значением хМЪНеЕрВеаиезе. Он добавляет пару “ключ/значение” как к полезной на- 
грузке РОЗТ (ВечиезЕ.Егоп), так и в коллекцию заголовков НТТР (Ведиез® .Неадегз). 
Это проще всего обнаружить с помощью вызова Т5А)]ахвеаиез* ()3 — расширяющего 
метода НЕЕрКедиез®Вазе. 

Рассмотрим пример: 


руБ11с АсЕ1опБези1е сеЕТ1ме (3Ег1пд хопе) 
{ 
РаЕеТ1те е1ще = РатеТ1те .ОесМои .АЧЯНочгз (ОЕЕзеез [хопе}); 
1 (Ведцез*.ТзА)ахВесиезь()) { 
// Сгенерировать фрагмент НТМ1-разметки 
зЕк1па ЕгадиепЕ = зЕг1па.Гокта® ( 
"<а1у>ТЬе еше 11 {0} 13 {1:1:ММ:5$$ ЕЕ} </Яру>", гопе.То0ррег(), Е1те); 


ь Обратите внимание, что ТзА} ахВесиез® () является методом, а не свойством, потому что в 
СЯ 3.0 отсутствует концепция расширяющих свойств. 
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гесиги Сопеепе (Егадшепе) ; 


} 
е1зе { 
// Сгенерировать полную НТМЬ-страницу 
гееакги У1еи (Е ше); 
} 
} 


Это один из способов сохранения полезного поведения для браузеров с отключенной 
поддержкой УДауабспрь, поскольку здесь вся страница заменяется ответом метода. Далее 
в главе будет описан более сложный подход к решению данной задачи. 


Асинхронная отправка форм с использованием 
мтода Азах .ВедлпЕохгт 


Иногда может понадобиться включить переданные пользователем данные в асинхрон- 
ный запрос. Для этого используется вспомогательный метод Азах.Вед1пЕоги (), прини- 
мающий примерно те же параметры, что и Нет .ВедтоЕогт(), плюс объект А} ахОр1опз, 
свойства которого были перечислены в табл. 12.1. 


Например, модифицируйте шаблон представления из предыдущего примера так, как 
показано ниже: 


<В2>МТаЕ Еле 1$ 1&?</62> 
<$%$ ив1па (А]ах .Вед1пЕоги ("СефТате", 
пем А}ахОр%1опз { ОрдафеТтагдеета = "муВезо1з" })) { %> 


<р> 
ЗЬои ме ЕБе &1ме 1: 
<зе1есе паме="2опе"> 
<орЕфоп уа1те="ис">0ТС</ор1оп> 
<ор&1оп уа1ае="Ьзе">В$Т</орЕ1оп> 
<ороп уа1ае="тае">МОТ</ор1оп> 
</зе1ес®> 
<1приЕ вуре="зыЪт1е" ха1ае="Со" /> 
</р> 
<% } %> 


<Ч1у 1а="туВези1$" зЕу1е="рогаег: 2рх ЧосЕеЯ геЯ; рада1та: „5ещ;"> 
Вези1Е5$ м111 арреаг Веге 
</а91у> 
<р> 
Тр1з раде маз депегаееЯ аЕ <%= РакеТ1те. ОесМом .Тобек1па ("В :ММ:з8 ЕЕ") %> (ОТС) 
</р> 

Даже не изменяя метода действия сееТ1ше (), мы сразу же получили пользователь- 
ский интерфейс, приведенный на рис. 12.3. 

Это все сведения, касающиеся метода А) ах.Вед1пРоги(). По сути, он представля- 
ет собой результат скрещивания методов Неп1.Вед1пгоги() и Адах.АсезорГаик (). Все 
конфигурационные опции он наследует от своих родителей. 

Асинхронные формы работают особенно эффективно, когда отображают результаты 
поиска без полностраничного обновления или обеспечивают возможность независимо- 
го редактирования каждой строки в экранной сетке. 


Вызов команд Чауа сирЕ из метода действия 


В главе 9 упоминалось, что АЗРМЕТ МУС включает тип результата действия по име- 
НИ Зауа$сг1рЕВези1е. Он позволяет вернуть из метода действия оператор Уауа$спре. 


416 часть |. АЗРМЕТ МУС во всех деталях 


‚ У ВаЕние 5 #2 


| 

| Эволу не №е Фипе НЕ Чяс + Со; 
| с; 
РЕ" 
| 

| 

| 

| 


Рис. 12.3. Метод А)ах.ВедлиЕоги() вставляет ответ в элемент ООМ 


Встроенные в АЗРМЕТ МУС вспомогательные методы А}ах.* спроектированы так, 
чтобы замечать, когда это делается“, и они выполняют это оператор Зауа$сирЕ вместо 
вставки его в виде текста в РОМ. Это удобно, когда на стороне сервере предпринима- 
ется какое-то действие и требуется обновить РОМ клиентской стороны для отражения 
произошедитих изменений. 

Рассмотрим приведенный ниже фрагмент шаблона представления. В нем выводится 
список товаров. Рядом с каждым товаром имеется ссылка Чеее (удалить), визуализи- 
рованная с помощью метода Адах.АсЕ1оптлок(). Обратите внимание, что последний 
параметр, переданный Адах.Асетопт лик (), имеет значение пи11, потому что при ис- 
пользовании Зауа5 сг1рЕВези1е указывать конкретное значение А} ахОрЕ1опз не обяза- 
тельно. Результирующий вывод показан на рис. 12.4. 


<в2>115Е оЕЁ 1%епз</Ь2> 
<Ч1у 14="пеззаде"></91у> 
<01> 
<% ЕогеасВ (уаг 15ем 1п Мо4е1) { %> 
<11 19="1Ееш <%= 16ет.Теештр %>"> 
<Ь><$%= 1Ееш.Мате %></> 
*= А]ах.АсЕ1опЬлик ("ае1еее", "Ре1ебетеен", пеи {15ет.Тееттр}, пи11) $> 
о 
<$ } %> 
</и1> 
<1>Раде депегаееа аф <%= РафеТ1ще .Мом.ТоГопаТииебег4иа() %></1> 


| Е Не - еглай Екрузиее 


= ых < Рергйосаовыя оленя 


экз тросов ри неоесоенлкь. 


115 ОЁ Нен< 


НВА оао т Иры ада 


Рис. 12.4. Набор ссылок, вызывающих запросы Аах 


“Тип Зауа$сг1реВезо1е устанавливает сопЕепе-хуре ответа в арр11сае1оп/х-Зауазск1 ре. 
Вспомогательные методы Азах.* специально ищут это значение. 
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Когда пользователь щелкает на ссылке две, она асинхронно вызывает действие, 
именуемое Ре1есеТ+ет, и передает ему параметр 1хештр. Метод действия должен со- 
общить уровню модели, что тому следует удалить запрошенный элемент. После этого 
можете потребоваться, чтобы метод действия проинструктировал браузер о необходи- 
мости обновления его РОМ для отражения проведенного изменения. Реализовать метод 
действия Ре1екеГеет() можно следующим образом: 


[АссереУегоз (НЕЕрУегЬз .РозЕ)] // Разрешить только запросы РОЗТ 
// (зто действие вызывает изменения) 
рУБ11с Фауа$ск1реВези1е Ре1екетТеем (1пЕ 1еештТр) 
{ 
уаг 1еепТоре1ете = бееТеем(1Еептр); 
// ТОРО: заставить уровень модели удалить 1тепТоре1теке 
// Сообщить браузеру о необходимости обновления РОМ 
уаг зсх1ре = з&х1па.Еогта% ("Опт Еепре1ефеа({0}, {1})", 
1фепТоре1ефе .т+фештр, 


Зауа$сг1рЕЕпсоде (1+епТоре1ефе .Маше)); 
гееагп Зауабск1ре (зсгар+); 


} 

ре1туаее збаЕ1с 51119 Фаха$сгарЕЕпсоде (з6г1пд з%г) 

{ 
// Закодировать определенные символы, 
// иначе выражение Фауабсг1ре может быть неверным 
тегаги пем дауабсг1рЕЗег1а11тег().Зег1а11те (36г); 


} 

Ключевой момент, на который здесь нужно обратить внимание, состоит в том, что 
в результате вызова Зауа$ст1ре() может быть возвращено выражение Зауа$спрё — в 
данном случае выражение виде Оптеепре1еееа (25, "ИмяЭлемента") — и оно будет вы- 
полнено на клиенте. Разумеется, оно будет работать, только если определена функция 
ОпТеепре1еееа (): 


<зсг1ре суре="Еехе/}ауазскаре"> 
ГопсЕ1оп ОптЕепре1ееей (14, папе) { 
Чоситепе . десЕ1епепЕВуТА ("пеззаде") .1ппекНТМЬ = ваще + " иаз детекеа"; 
уаг Че1етеЯМоае = Чоситепе - де Е1етерЕВуТА ("1 кеш" + 1а); 
Че1ефеЯМоде .рагепЕМоде . гетоуеСь119 (Яе1екедМоаде) ; 
} 
</зск1рЕ> 


Резульгирующее поведение иллюстрируется на рис. 12.5. 


[| 25 пы Баегле Борки Вы 


Е 9 я 18] Веру лов озьЗТЗОАН 


1156 оЁ Нет$ 


=» ЕгенсН 


} 
| ® С:аБана пе 
] р 
а 


Рис. 12.5. Каждый щелчок на ссылке Чеее заставляет браузер получить 
от сервера и выполнить команду Зама5 сир 
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Хотя такое применение Фауа$сг1рЕВези1е может показаться удобным, следует 
тщательно подумать, прежде чем рептиться на это. Встраивание Чауа$сирЕкода не- 
посредственно в метод действия похоже на встраивание в него литерального запроса 
ЭОГ или литерального НТМГ: это нежелательное смептение технологий. Генерация кода 
ЧауаЗсирЕ с использованием конкатенаций строк .МЕТ жестко и сильно связывает код 
серверной стороны с кодом на стороне клиента. 

В качестве более аккуратной альтернативы можно вернуть УзопВези1е из метода 
действия и воспользоваться }Очегу для его интерпретации и обновления РОМ браузе- 
ра. Это избавляет как от сильной связи, так и от проблем с кодированием строк. Далее 
в настоящей главе будет показано, как зто делается. 


Обзор вспомогательных методов А}ах .* в АЗР.МЕТ МУС 


Как было видно в предыдущих примерах, использовать вспомогательные методы 
А)]ах.* очень легко. Обычно они не требуют написания какого-то ЗауаЗсир!-кода и ав- 
томатически учитывают конфигурацию маритрутизации во время генерирования ОВТ.. 
Часто метод А)ах.Асетортаик() оказывается именно тем, что нужно для получения 
простого фрагмента Адах — он выполняет свою работу быстро, без шума и пыли, что 
очень хорошо! Но иногда может потребоваться нечто более мотцное, поскольку вспомо- 
гательные методы Адах.* ограничены в перечисленных ниже отношениях. 


® С их помощью можно выполнять лишь простые обновления страниц. Они могут 
включать готовый блок НТМГ-разметки в существующую страницу, но не имеют 
поддержки для извлечения и обработки низкоуровневых данных (например, дан- 
ных в формате 4ЗОМ), и единственный способ настройки их манипуляции моде- 
лью РОМ состоит в возврате оператора ЧауаЗсир{ из метода действия. 


® При обновлении модели РОМ они просто делают элементы видимыми и невиди- 
мыми. Здесь не предусмотрено встроенной поддержки постепенного появления 
или исчезновения элементов, равно как и других разновидностей анимации. 


® Используемая модель программирования не гарантирует удовлетворительного по- 
ведения при отключенной поддержке Зауа сре. 


Чтобы преодолеть эти ограничения, можно написать собственный низкоуровневый 
код Чауасйре (и вручную ренптать проблемы совместимости) или же обратиться к пол- 
ноценной библиотеке ДауаЗспПр. 

Например, можно было бы напрямую работать с библиотекой АЗРМЕТ АЧАХ. Однако 
это тяжеловесное решение: основное назначение этой библиотеки — поддержка раз- 
витой модели событий и элементов управления серверной стороны АЗРМЕТ \еБЕогилз, 
которая не особенно интересует разработчиков АЗРМЕТ МУС. В рамках АЗРМЕТ МУС 
имеется возможность использовать любую библиотеку Аах или Зауа$сире. 

Наиболее популярный выбор, судя по мнению большинства веб-разработчиков в 
мире — ]Очету. Этот вариант настолько популярен, что Масгозой теперь поставляет 
]Эчегу вместе с АЗРМЕТ МУС и обещает включить его в состав У1зца! 5ба@1о 2010, не- 
смотря на то. что данный продукт не принадлежит Мсгозой. Чем это объясняется? 


Использование |Сбиегу в АЗР.МЕТ МУС 


Меныише кода, больше функций — зто основное обещание ]|Фчегу, свободной библиотеки 
Чауа$сирЕ с открытым исходным кодом, которая впервые появилась в 2006 г. Она заслу- 
жила массовое одобрение веб-разработчиков на всех платформах, потому что избавила 


5 Она доступна для коммерческого и персонального использования на условиях лицензий МТ 
и СР|. 
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их от бремени кодирования на стороны клиента. Библиотека |Оцегу предлагает злегант- 
ный синтаксис на основе С$$-3 для обхода дерева модели ПОМ, удобный АРГ-интерфейс 
для манипулирования и анимации элементов РОМ и исключительно лаконичные обо- 
лочки для вызовов А]ах — все это тщательно абстрагировано для устранения различий 
между браузерамиб. Данная библиотека расптиряема, имеет богатую экосистему свободно 
доступных подключаемых модулей и стимулирует стиль кодирования, позволяющий со- 
хранить базовую функциональность, когда поддержка Зауа$сирЕ недоступна. 

Звучит слишком хорошо, чтобы быть правдой? На самом деле, нельзя гарантиро- 
вать, что библиотека ]Очегу упростит вообще все кодирование на стороне клиента, но 
обычно применять ]Очцегу намного легче, чем писать низкоуровневый код ЛауаЗсирь, к 
тому же она отлично работает с АЗРМЕТ МУС. Ниже вы ознакомитесь с теоретическими 
аспектами, положенными в основу библиотеки {Очету, и увидите ее в действии, добавив 
некоторый лоск к типичным действиям и представлениям АЗРМЕТ МУС. 


Ссылки на библиотеку |Оиегу 


Каждый новый проект АЗРМЕТ МУС уже содержит библиотеку |Очегу в своей папке 
/Зсгарез. Подобно многим другим библиотекам Чауа$сирё, это просто единственный 
файл .}з. Чтобы использовать его, необходимо только на него сослаться. 

Например, добавьте в начало раздела <Веа9> мастер-страницы приложения следую- 
щий дескриптор <зск1ре>: 


<ВеаЯ гипаЕ="зегуег"> 
<зскаре згс="<%= 9г1.Сопфепе ("-/$сг1рез/)аегу-1.3.2.м1п.35") %>" 
фуре="+ехе/)ауазсгар®"></вскг1ре> 
<!-- Оставить без изменений --> 
</Веаа> 


Файл )чаиегу-1.3.2.п4п.)з хранит уменьшенную версию библиотеки. Это означает, 
что все комментарии, длинные имена переменных и излишние пробелы исключаются 
для сокращения времени загрузки. Для того чтобы разобраться в исходном коде |Оиету, 
вместо этого следует читать файл с обычной версией (3 чиегу-1.3.2.33). 

Последняя версия библиотеки ]Оцегу доступна для загрузки по адресу ВЕЕр:// 
Эачеку-соп/. Загрузите основной файл библиотеки ]Очегу. поместите его в папку 
/Зсг1рЕз приложения и затем установите ссылку на нее, как было показано выше. На 
момент подготовки русскоязычного издания книги последней версией была 1.4. 


Поддержка средства ИЧе!Ш$еп$е для |Оцегу 


Нужна ли здесь поддержка со стороны 1щеШ$епзе? Обеспечение поддержки средства !1еЗепзе 
для по-настоящему динамических языков, таких как ЧамаЗсир\, представляет фундаментальную 
трудность, потому что функции могут добавляться и удаляться из индивидуальных экземпляров 
объектов во время выполнения, и все функции могут либо возвращать что-то, либо не возвра- 
щать ничего. Среда \Лзиа! Зи о 2008 старается разобраться с тем, что происходит в коде, но 
в действительности это работает, только если создан файл .узаос, содержащий подсказки о 
работе кода уфама5сиру. 


Команда создателей \Л5ца! Зи ю в сотрудничестве с командой |Сиегу разработала специаль- 
ный файл .узаос, который значительно улучшил поддержку ме! Зепзе для |Очцегу. Этот файл 
Эачегку-1.3.2-у54ос.)5 по умолчанию уже включен в папку /5ск1рез приложения (более 
новые версии доступны по адресу ВЕЕр: / /Чосз. чиеку . сот/Роип1оа91та_1Оиегу). Для 
его использования просто добавьте ссылку на него. 


6 В настоящее время поддерживаются браузеры Егеюх 2.0+, Пцегпеё Ехр]огег 6+, За З+, 
Орега 9+ и СБготе 1+. 
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Поместите следующую строку внутрь элемента <азр: РласеНо19ег> в разделе <Ъеад> мастер-страницы: 
<% /* %><вст1ре згс="-/5ск1рЕз/]ацегку-1.3.2-уз9ос.)3"></зск1ре><% */ %> 
Обратите внимание, что зтот дескриптор <зск1рЕ> служит лишь подсказкой для М зца! Зи: он 
никогда не будет визуализирован в браузере, потому что оформлен как комментарий серверной 
стороны. Следовательно, на файл необходимо ссылаться с использованием его виртуального пути, 
как показано, и не разрешать этот путь с помощью 01 .Сопеере () , как зто делается для других 
дескрипторов <зсг1ре>. В случае применения частичных представлений (файлов АЗСХ), к сожа- 
лению, придется дублировать зту строку в начале каждого файла, потому что файлы АЗСХ не ас- 
социированы с мастер-страницами. 


Можно надеяться, что зта несколько замысловатая настройка будет упрощена в будущей версии 
\зиа! Зи. Хотя можно загрузить заплату, которая заставит \/бца! З1и0о автоматически находить 
файлы *-узаос. ] з, но она не поможет, если основной файл |иегу импортируется посредством 
01 .Сопеер® (), как и не решит проблемы с файлами АЗСХ. За дополнительными деталями об- 
ращайтесь по адресу Веер: //Е1пуик1 . соп/] ОТпЕе1115епзе. 


Теория, положенная в основу ]биегу 


В основе ]Оцегу лежит мощная ЗауасирЕ функция по имени }Оцегу(). Ее можно 
использовать для запроса у РОМ всех элементов НТМГ-страницы, соответствующих ка- 
кому-то селектору С5$. Например, }Оцегу ("РТУ.МуС1азз") найдет все элементы д1у в 
документе, которые имеют класс С$$ по имени МуС1азз. 

Функция )Оцегу() вернет упакованный набор ]Оиегу, те. объект ЗауаЗсирь, в ко- 
тором перечислены результаты и имеется множество дополнительных методов, кото- 
рые можно вызывать для того, чтобы оперировать этими результатами. Болыпая часть 
АР!-интерфейса ]|Оцегу состоит из вызовов этих методов на упакованных наборах. 
Например, }Оцеку ("РТУ.Мус1азз") .В14е() немедленно скроет все соответствующие 
элементы а1ту. Для краткости в ]Оцегу предусмотрен и сокращенный синтаксис $ (); это 
то же самое, что и вызов }Оцеку ()”. В табл. 12.3 приведены примеры его применения. 


Таблица 12.3. Простые примеры применения {Оиегу 


Код Эффект 

$("Р ЗРАМ") .аааСТазз ("5ирегВ19" ) Добавляет класс С$$ по имени ЗирегВ+ а ко всем 
узлам <зрап>, содержащимся в узле <р>. 

$(".5ирегВ19") .гепоуеСТазз ("ЗирегЕ19") Удаляет класс С$$ по имени 5ирегВ1с из всех узлов, 
включающих его. 

$ ("форЕ1опз") . Соботе () Переключает видимость злемента с идентификатором 


орЕ1опз (если он видимый, то скрывается, а если уже 
скрыт, то показывается). 


$ ("рт\у:Вав (ТМРОТ [фуре=' свескрох' | : Вставляет НТМЕ-разметку <1>Неу! </1> в начало всех 
Ч1заЪ\еа) ") .ргерепа ("<{>Неу!</1>") элементов 91”, содержащих отключенный флажок. 

$ ("#орётойз А") .с55("со1ог", "хеб"). Находит любые дескрипторы гиперссылок (т.е. <а>), 
ГадеОие () содержащиеся внутри элемента с идентификатором 


орЕ1опз, устанавливая красный цвет для их текста 
и постепенно делая их невидимыми за счет снижения 
непрозрачности до нуля. 


7 В терминах Зауа$ сре это все равно, что записать $ == }Оцегу (функции также являются объ- 
ектами). Если вам не нравится синтаксис $(), возможно потому. он конфликтует с какой-то 
другой используемой библиотекой ЗауасйрЕ (например, Ргоюуре, где также определено $}, 
можете отключить этот синтаксис вызовом )Оцегу .поСопЕ11СЕ (). 
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Как видите, синтаксис исключительно краткий. Написание того же самого кода без 
]Очегу потребовало бы множества строк ЗауаЗсйр+. В последних двух примерах демон- 
стрируются два важных средства ]Очегу. 


» Поддержка С5$ 3. Предоставляя селекторы для }3Очегу. можно использовать боль- 
шую часть синтаксиса, совместимого с С$$ 3, независимо от того, поддерживает 
ли его браузер. К этому синтаксису относятся псевдоклассы вроде :Ваз (дочерний 
селектор), : Е1т5®-сЬ11а, : ПЕБ-сЬ11а и : поЁ (селектор) ‚ селекторы атрибутов, 
подобные * [а {='уа1'] (соответствует узлам с атрибутами ас (="уа1"), родст- 
венные комбинаторы, такие как саб1е + р (соответствует абзацам, непосредст- 
венно следующим за таблицей), и дочерние комбинаторы, например, Боду > блу 
(соответствует элементам 1х, которые являются непосредственно дочерними по 
отнонению к узлу <Боду>). 


» Связывание методов в цепочки. Почти все методы, которые воздействуют на 
упакованные наборы, также возвращают упакованные наборы, позтому их вы- 
зовы можете связывать в цепочки (например, $ (зе1есфог) .абс().аеЕЁ().981()), 
получая чрезвычайно лаконичный код. 


Далее вы ознакомитесь с }Очегу, как с автономной библиотекой. После этого будет 
показано, как использовать многие ее средства в приложении АЗРМЕТ МУС. 


На заметку! Данный материал не претендует на полное руководство по |Сиегу, поскольку это от- 
дельная от АЗРМЕТ МУ\УС библиотека. Ниже просто демонстрируется, каким образом |Оиегу 
взаимодействует с АЗРМЕТ М\УС без документирования всех вызовов методов и их многочис- 
ленных опций; все это можно легко найти в онлайновом руководстве по адресу НсЕр: //досз. 
Зацеку.сом/ или ВЕЪр: / /у1зца1] ацеку.соп/). 


Краткое примечание об идентификаторах элементов 


Если вы используете |Очегу или пишете код ауасиИрЕ для работы с приложением АЗРМЕТ МУС, 
вам следует знать о том, как встроенные вспомогательные методы элементов управления вводом 
генерируют атрибуты идентификаторов (19). Приведенный ниже вызов вспомогательного метода 
тестового поля: 


<$= НЕ]. ТехЕВох ("р1еаде.Апоипе") $%> 
приводит к получению следующего кода: 
<1приё 149="р1едде Атоип®" папме="р1едде.Атоцпе" фуре="бехе" уа1ие="" /> 


Обратите внимание, что именем элемента является р1едде.Атоиле (без точки), но его иден- 
тификатор выглядит как р1едде_ Атоипе (со знаком подчеркивания). При генерации идентифи- 
каторов злементов все встроенные вспомогательные методы автоматически заменяют символы 
точки подчеркиваниями. Это позволяет ссылаться на результирующие элементы, используя се- 
лектор {иегу вида $ ("#р1едде_Аптоипе"). Следует отметить, что было бы неправильно запи- 
сать $ ("#р1едде .Амочпе") , потому что в |@иегу (и в С$$) зто означает элемент с идентифика- 
тором р1едае и С$$-классом Атоппе. 


Если по какой-то причине подчеркивания не устраивают, и необходимо, чтобы вспомогательные 
методы заменяли точки другим символом, например, знаком доллара, альтернативную замену 
можно сконфигурировать следующим образом: 

Не] Не1рех.ТаАЕЕтг1юиферо®Вер1асемеюЕ = "5"; 

Это делается лишь один раз во время инициализации приложения, например, добавлением пока- 
занной выше строки к функции Арр11саЕ1оп _5%ах®е() в файле с1оБа1.азах. сз. Но поскольку 
подчеркивания работают вполне нормально, вряд ли понадобится изменять зту установку. 
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Ожидание загрузки ВОМ 


Болышпинство браузеров запускает код ЗауаЗсйрЕ сразу, как только анализатор стра- 
ницы сталкивается с ним, даже перед завершением загрузки страницы браузером. Здесь 
может возникнуть проблема, потому что если поместить некоторый код Зауа$сире в 
раздел <Беа4> в начале НТМГ.-страницы, то этот код не сможет оперировать остальной 
частью НТМГ-докумевта, так как она еще не загружена. 

Традиционно веб-разработчики рептали эту проблему, вызывая код инициализации в 
обработчике оп1оаа, присоединенном к элементу <Ъоду>. Это гарантирует выполнение 
кода только после полной загрузки документа. С таким подходом связаны два недостатка. 


1. Дескриптор <Боау> может иметь только один атрибут оп1оа4, позтому трудно 
комбинировать несколько независимых частей кода. 


2. Обработчик оп1оа4 ожидает загрузку не только РОМ, но также и всего внешнего 
содержимого (такого как графические изображения). Скорость реакции насьшщен- 
ного пользовательского интерфейса может снизиться, особенно при медленных 
соединениях. 


Идеальное решение состоит в том, чтобы заставить браузер запустить стартовый 
код, как только будет готова модель РОМ, но не ожидая загрузки внешних ресурсов. 
АРГ-интерфейс для этого варьируется от браузера к браузеру, но }Очегу предлагает про- 
стую абстракцию, которая работает с ними всеми. Вот как она выглядит: 

<8скаре> 

$ (ЕопсЕтог () { 
// Сюда поместить код инициализации 


р; 
</зсг1рЕ> 


Передав ЧауаЗсир-функцию вызову $ (), как это сделано с анонимной функцией в 
приведенном выше коде, вы зарегистрируете ее для выполнения сразу же по готовности 
модели РОМ. Регистрировать можно произвольное количество функций, однако обычно 
пишут единственный блок $ (Еипсе1оп () {... }); в начале шаблона представления и 
помещают туда все поведение }Очегу. Этот подход будет демонстрироваться во многих 
примерах в настоящей главе. 


Обработка событий 


Возможность присоединения кода ЗауаЗсйр для обработки событий пользователь- 
ского интерфейса клиентской стороны (таких как с11ск, Кеудомт и оси) появилась 
еще во времена браузера Мезсаре Мамвафог 2 (1996 г). В первые несколько лет АР|- 
интерфейсы для обработки событий в разных браузерах были совертенно несовмести- 
мыми: отличался не только синтаксис регистрации события, но также механизмы рас- 
пространения событий и имена часто используемых свойств событий (например, расдех, 
зсгеепХ или с11еп%Х?). Браузер Пфегоеё Ехрогег прославился своим патологическим 
стремлением к оригинальности. 

За время, прошедшее с тех темных веков, современные браузеры стали не намного 
лучше! Десятилетие спустя все по-прежнему пребывает в состоянии анархии, и даже 
несмотря на то, консорциум \/ЗС ратифицировал стандартный АР!-интерфейс для об- 
работки событий (иии .и3 . оха/ТВ/РОМ-Теуе1-2-ЕуепЕ5/еуепе$ .Нт1), лишь несколько 
браузеров поддерживают его болыпую часть. В современном мире, где так распростра- 
нены 1РЬопез. №тепдо У/15 и маленькие нетбуки под управлением Шпих, приложение 
должно поддерживать невероятное разнообразие браузеров и платформ. 

Создатели библиотеки ]Фчегу приложили серьезные усилия к решению зтой пробле- 
мы. Эта библиотека предлагает абстрактный уровень над встроенным ЗауаЗ ср АРТ 
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браузера. поэтому код будет работать почти одинаково в любом браузере, поддерживаю- 
щем }Очегу. Синтаксис обработки событий выглядит замечательно, например: 


$ ("ла") . с11ск (ЕипсЕтор() { $ (613) .Еадеоие() }) 
Этот код заставляет каждое изображение постепенно исчезать после щелчка на нем. 


(Очевидно, что приведенную строку кода понадобится поместить внутрь дескрипторов 
<зсу1рЕ></зск1рт>.) 


На заметку! Недоумеваете, что означает $ (515)? В обработчике событий Чауабсир-переменная 
{515 ссылается на элемент РОМ, принимающий событие. Однако это обычный старый зле- 
мент РОМ, поэтому у него нет метода Еааеб® (). Решение состоит в написании $ (ЕЪ1 3), что 
создает упакованный набор (содержащий единственный элемент +113), обладающий всеми 
возможностями упакованного набора |иегу (включая метод Еадеоче ()). 


Обратите внимание, что больше нет необходимости беспокоиться о разнице между 
аЧ9дЕхепеТ15тепег () для соответствующих стандарту браузеров и аадЕхепЕТаА з$епег () 
для Пцегпеё Ехрогег 6. Кроме того, теперь можно обойтись без неудобного включе- 
ния кода обработчика события непосредственно в определение элемента (например, 
<119 з:с="..." опс11ск="некоторый код Фауабск1ре“/ >), который не поддерживает 
множественные обработчики событий. Дополнительные примеры обработки событий 
]Очегу будут показаны ниже. 


Глобальные вспомогательные функции 


Помимо методов, которые оперируют с упакованными наборами, в }Очегу имеется 
ряд глобальных свойств и функций, спроектированных для упрощения работы с Аахи 
написания сценариев для множества браузеров с учетом различий их блочных моделей. 
Средства Ауах в }Очегу рассматриваются далее в главе. В табл. 12.4 приведены некото- 
рые примеры других вспомогательных функций |Фиегу. 


Таблица 12.4. Некоторые глобальные вспомогательные функции, 
предлагаемые библиотекой ]Оиегу 


Функция Описание 


$.Югоизех Сообщает, какой браузер запущен, согласно строки изех-адепе. Одно из 
следующих свойств установлено в ские: $.Югомзег .из1е, $ .Бхомзехг. 
по7111а, $.юкомзег.заЕахи] или $ .Ютомзег.орега. 


$.Югоизег.уегзЗоп Сообщает версию запущенного браузера. 


$.зирроге Определяет поддержку браузером разнообразных средств. Например, 
$. зиррог®.ЪохМоде1 определяет, визуализируется ли текущий фрейм 
согласно стандартной блочной модели М!ЗС*. Полный список возможностей, 
которые может обнаружить $ . зирроге, описан в документации по [Оцегу. 


$. ЕЕ (5) Возвращает строку зЕх с удаленными ведущими и хвостовыми пробелами. 
Юиегу предлагает эту удобную функцию потому, что, как ни странно, она от- 
сутствует в стандартной библиотеке Чамабсири. 


$.1пАкгау(уа1, агг) Возвращает первый индекс хха1 в массиве ахх. Библиотека {Оиегу содержит 
эту полезную функцию потому, что браузер Нфегпе! Ехрогег, по крайней мере, 


версии 7, не поддерживает функцию аггау.1пдехоеЕ (). 
Е ЕЕ а 


* Блочная модель определяет, каким образом браузер располагает элементы и вычисляет их размеры, а 
также то, как стили рада1 пд и Богаех учитываются в принятии решения. Это может варьироваться в 
зависимости от версии браузера и типа РОСТУРЕ, объявленного на НТМЕ-странице. Иногда эту инфор- 
мацию можно использовать для устранения различий в компоновке между браузерами за счет коррек- 
тировки стиля рад 91 пс и других стилей С$$. 
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Это не весь набор вспомогательных функций и свойств {Фиегу, впрочем, полный на- 
бор на самом деле довольно мал. Ядро ]Очегу спроектировано так, чтобы быть компакт- 
ным для быстрой загрузки, но при этом допускать расптирения, чтобы всегда можно 
было написать подключаемый модуль для добавления собственных вспомогательных 
функций. которые оперируют упакованными наборами. 


Ненавязчивый уауа$спрЕ 


Теперь почти все готово к тому. чтобы приступить к применению |@чегу в АЗРМЕТ 
МУС, но есть еще одно теоретическое понятие, к которому следует привыкнуть: нена- 
вязчивый Чаша спреё 

Что это такое? Это принцип сохранения кода ЗауаЗсИре чистым и физически отде- 
ленным от НТМГ-разметки, с которой он работает, с целью сохранения НТМ1-порции в 
функциональном состоянии. Например, не следует писать код наподобие: 

<а1\у 1а="ту11оКкз"> 

<а ВгеЕ="#" опс11ск="1Е (сопЕт км ( "Ко11ом ЕНе 11иК?'))} 


Тоса®1оп.ВгеЕ = '/зопе0к11';">Тлик 1</а> 
<а ВгеЁ="$" опс11сК="тЕ (сопЕ1 гм ('Ро11ои ЕБе 1140К?')) 
ПТосаЕ1оп.ВгеЕ = '/зоще0к12';">Ьлок 2</а> 


</а1у> 


Код должен выглядеть следующим образом: 


<а1у 19="пу110Кз"> 
<а пхеЕ=" /зоше0х11">Т1иКк 1</а> 
<а ВхеЕ=“" /зопе0к12">11ик 2</а> 
</91у> 
<8сг1рЕ туре="$ехе/)ауазсг1р®"> 
$ ("Рту11тКз а") .с11сК(Еипсефор () { 
тебагп сопЕ1 км ("Ео11ом ЕБе 11пК?"); 
}); 
</зсгаре> 


Второй вариант кода лучше не только потому, что его легче читать, и не потому, 
что в нем исключено повторение фрагментов кода. Ключевое преимущество его состоит 
в том, что он остается функциональным даже в браузерах, которые не поддерживают 
ЗахуаЗсирЕ. Ссылки при этом работают подобно обычным ссылкам. 

Ниже описан процесс проектирования, который позволяет обеспечить ненавязчи- 
вость ЧЗауа спирт. 


» Сначала постройте приложение, вообще не используя ЗауаЗсирф, приняв ограни- 
чения простого старого НТМГ/С$$ и добившись жизнеспособной (хотя и базовой) 
функциональности. 


® После зтого приступайте к добавлению любого предпочитаемого межбраузерного 
кода ЗауаэсПрЕ — Адах, анимации, словом, всего, что хотите! Только не трогайте 
исходную разметку. Сценарий ЗауаЗ сре предпочтительнее размещать в отдель- 
ном файле. Это будет напоминать о том, что сценарии — нечто отдельное. В ре- 
зульгате можно будет радикально расширять функциональность приложения, не 
влияя на его поведение при отключенном Зауаспре. 


Поскольку ненавязчивый ЗауаЭсирЕ не нужно внедрять во множество разных мест 
НТМГ-документа, шаблоны представлений МУС также могут быть упрощены. В частно- 
сти, это избавит от необходимости конструировать код Зауасирь, манипулируя строка- 
ми на стороне сервера в цикле <% Еогеась(...) $%>. 

Библиотека |Фчцегу делает относительно простым добавление ненавязчивого уровня 
Чахазсирекода, так как после построения чистой разметки без сценариев подключение 
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изошренного поведения или привлекательное оформление обычно сводится к нескольким 
вызовам функций из ]Очегу. Давайте рассмотрим некоторые реалистичные примеры. 


Добавление интерактивности на стороне 
клиента к представлению МУС 


Экранные сетки, как правило, нравятся всем. Предположим, что имеется класс мо- 
дели по имени Моппса1птпЕо, определенный следующим образом: 


ру11с с1аз5 Моппта1пТоЕо 
{ 
рую11с зЕк1па Маше { дее; зе{; } 
риф11с 106 НетайЕТиМетет$ { деф; зеф; } 
} 


Коллекцию объектов Моипеа1о1трюЕо можно визуализировать в виде сетки, используя 
строго типизированный по типу модели тЕпимегаЪ1е<Моипфа1итТиЕо> шаблон представ- 
ления, который содержит следующую разметку: 


<В2>ТНе Зеуеп $ити1$</62> 
<а1у 19="зити1Е8"> 


<Еаю1е> 
<{Веаа><Ех> 
<Е9>ТЕеп</®а> <Еа>Нелане (м) </$а9> <ЕА>АСЕ1овз</6а> 
</Ех></Ереаа> 
<% ЕогеасВ (уах тоипбалп 1п Мо@9е]1) { $%> 
<Ек> 
<&9><$= моппбалп.Маще %$></%4> 
<Е9><$%= тоцрбалзт.НезовеТоМееехтз %></$а> 
<Еа> 
<% из1па (НЕ .ВедлиЕоги("ре1ефетеем", "Нопе")) { %> 
<%= НЕш1.Н1Ч4ер ("15ет", поипбалп.Маше) %> 
<1приЕ Суре="зобт1®" уа1ае=“Бе1еее" /> 
<% $> 
</Еа> 
</Ег> 
<$ } $%> 
</Еаб1е> 
</а1у> 


Разметка не особо впечатляет, но работает, причем Чауазсир-кода здесь нет. 
Применив соответствующий стиль С$5 и подходящий метод действия Ре1ефкетфем(), 
можно получить внешний вид и поведение, показанное на рис. 12.6. 
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Рис. 12.6. Базовая сетка, полученная без использования уамабсире 
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Для реализации кнопок Бею«{е (Удалить) обычно применяется трюк “множественных 
форм”: каждая кнопка Бе!ейе помещается в собственный элемент <Еоги>, поэтому может 
запускать НТТР-запрос РОЗТ — без кода ЗахаЗсйрЕ. — направляемый к ОВТ, который 
соответствует удаляемому элементу. (Элементы, отображаемые в сетке. соответствуют 
названиям известных гор. Однако непростой вопрос о том, что означает “удаление” 
горы, мы здесь рассматривать не будем.) 

Теперь давайте поработаем над улучшением пользовательского интерфейса в трех 
направлениях, используя {Очегу. Ни одно из рассматриваемых далее изменений не ока- 
зывает влияния на поведение приложения при отключенном Зауа сре. 


Улучшение 1: оформление сетки полосами 


Одним из типичным приемов веб-дизайна является оформление стиля четных и не- 
четных строк таблицы по-разному. В результате получаются горизонтальные полосы, 
которые помогают посетителю в визуальном восприятии зкранной сетки. Элементы 
управления АЗР.МЕТ расабг1а и ст1а\у1еи имеют встроенные средства для получения 
этого эффекта. В АЗРМЕТ МУС можно достичь того же самого, генерируя специальное 
имя класса С$35 для каждого четного дескринтора <Ег>: 

$ ШЕЕ =О; $%> 
<$ ЕогеасВ (уаг шоппфа1п 1п Мо@е1) { $%> 
<Ех <3= 14+ $2 == 1? "с1азз=‘а1]феграее"" ; "" $>> 


Согласитесь, что код выглядит не особенно изящно. В принципе, можно было бы 
воспользоваться псевдоклассом С$$ 3: 


Ех: пеВ-сй119 (еуеп) { БаскакоипЯ: 311уег; } 


Однако его поддерживают лишь немногие браузеры (на момент написания книги — 
только ЗаЁап!). Поэтому лучше добавить одну строку кода, связанного с ]Эчегу. Ее можно 
разместить в любом месте шаблона представления, например, в разделе <веа4> мастер- 
страницы или рядом с разметкой, которой это должно коснуться: 

<зсЕ1рЕ вуре="$ехе/)ауазст1ре"> 

$ (ЕопсЕтор () { 
$ ("ЁЕвишиа $ Ек:пЕЬ-ср119(еуеп)").сзз("Ьаскагоипа-со1ог", "за1уег"); 


}); 
</зсг1ре> 


Код будет работать в любом популярном браузере и отобразит то, что показано на 
рис. 12.7. 
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Рис. 12.7. Сетка, оформленная полосами 
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Обратите внимание на применение синтаксиса $ (Еопсе1от() { ... }); для реги- 
страции кода инициализации на запуск по готовности модули ООМ. 


На заметку! На протяжении оставщейся части главы напоминания о необходимости регистрации 
кода инициализации с использованием $ (Еопсе1опт() { ... }); больше даваться не будут. 
Просто помните, что код |@чегу, который должен выполняться только после инициализации мо- 
дели БОМ, необходимо размещать внутри блока $ (ЕорсЕ1оп () { ... }); страницы. 


Чтобы сделать код аккуратнее, можно воспользоваться сокращенным псевдоклассом 
]Очету :еуеп и применить соответствующий класс С55: 


$ ("#зипи16$ Ег:еуеп"“) .ад9С1а$$ ("а]фегпа®е"); 


Улучшение 2: подтверждение перед удалением 


Обычно перед выполнением важного необратимого действия, подобного удале- 
нию элемента, должно выдаваться предупреждение®. Не генерируйте фрагменты кода 
Захару в атрибутах опс11ск="..." или опзот1(="...", а назначайте все обработ- 
чики событий сразу с помощью ]Фчегу. Добавьте в блок инициализации следуюший 
фрагмент кода: 


$ ("#эзапилез Еоги[ас®1оп$=' /Ре1ебетеет' ]") забит (ЕорсЕфоп() { 
уахг 1ЕешТехе = $ ("1проЕ [папе='1{$ещ']", (61$) .уа1(); 
тегигп сопЕ1ти(“Аге уой зите уойи мапЕ Ко де1ефе '" + 1{ешТехЕ + "'?"); 


}); 


Этот запрос сканирует элементы зири1Ез в поиске узлов <Еоги>, которые отправ- 
ляются на ОВ! завершающийся строкой /ре1ететеет, и перехватывает их события 
заыт1 Е. Полученное в результате поведение показано на рис. 12.8. 


3 Бери Лоса оз ЗЕЯ оглейбыиития - Гете Ехругег |. м. Е 
ВНр/ Асса $52316 Ногле? ЗиглелИя 
Ней {1 АсНовз 
6961 | Сев, 


Ан несненыи о Сан ДИНЫ 


УбониЕ И 1 Узасниея Тиеетлей Екрогег 


Нет 
Еуегез 8848 : рее 
Асоасаана 

&® Агеуоц зуге уси манётс детеКе 'Емегезе7 


Рис. 12.8. Запуск обработчика события забит Е 


8 Еще лучше предоставить пользователю дополнительную возможность отменить действие 
даже после того, как оно подтверждено. Но это уже другая история. 
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Улучшение 3: сокрытие и отображение разделов страницы 


Еще один распространенный трюк состоит в сокрытии определенных разделов стра- 
ницы, пока в точности не станет известно, что они в данный момент актуальны для 
пользователя. Например, на сайте электронного магазина нет смысла отображать эле- 
менты для ввода информации о кредитной карте, пока пользователь не выберет вари- 
ант оплаты с ее помощью. Как упоминалось в предыдущей главе, это называется после- 
довательным раскрытием. 

В качестве другого примера может понадобиться сделать определенные столбцы 
сетки необязательными и скрывать или отображать их в зависимости от состояния 
флажка. Обычными средствами это реализовать довольно трудно: если сделать это на 
сервере (в стиле АЗРМЕТ Ме Рог), то придется выполнять утомительный обмен дан- 
ными между клиентом и сервером, управлять состоянием и писать запутанный код для 
отображения таблицы. Если же сделать это на стороне клиента, то придется принимать 
во внимание отличия в обработке событий и применении С$$ в разных браузерах (на- 
пример, отображать ячейки с использованием 91зр1ау:таю1е-се11 для соответствую- 
щих стандарту браузеров и 91зр1ау:Ъ1оск — для Гфегие{ Ехрюгег. 

Теперь обо всех этих проблемах можно смело забыть. Библиотека] @’иегу позволяет реа- 
лизовать такое поведение довольно просто. Добавьте следующий код инициализации: 


$("<1афе1><1приё 19='вБетанез' суре=' сресКЬох' 
свескед='{тгие' />5пом Вела з</1аЪе1>") 
.1пзехтЕВеЕоге ("#3015") 
. СЬ11 геп ("1 проб") .с11сК (Еопселоп () { 
$("#зиии1е$ Ба:пЕВ-св11а(2)") .содоле (); 
}) .с11ск(); 


Это и все, что понадобится. Передав строку НТМГ, вызову $ (), вы инструктируете 
]@чегу создать набор элементов РОМ, соответствующих разметке. Код динамически 
вставляет новый НТМГ.-элемент флажка перед элементом 551103 и затем привязывает 
обработчик события с11ск, который будет переключать отображение второго столбца в 
таблице. И, наконец, он вызывает событие с11ск флажка, поэтому по умолчанию фла- 
жок будет не отмечен, а столбец сетки — скрытым. Любые отличия между браузерами 
прозрачно обрабатываются уровнем абстракции {Очегу; Новое поведение можно видеть 
на рис. 12.9. 
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Рис. 12.9. Сокрытие и отображение столбца с помощью щелчка на флажке 
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Обратите внимание. что это по-настоящему ненавязчивый ЧауазсирЕ. Во-первых, он 
не предполагает внесение каких-либо изменений в сгенерированную сервером размет- 
ку для таблицы и, во-вторых, он не влияет на поведение при отключенной поддержке 
Заха$сйре. Если браузер не поддерживает Зауа5сирь, то флажок Эпом/ пеюот{$ (Показать 
высоты) даже не добавляется. 


Ссылки и формы с поддержкой А/ах 


Теперь давайте займемся чем-нибудь реальным. Ранее было показано, как использо- 
вать встроенные в АБРМЕТ МУС вспомогательные методы Адах для выполнения частич- 
ных обновлений страницы без написания кода Уауа5сИрЕ. Вы также узнали, что этому 
подходу присущ ряд ограничений. 

Для преодоления этих ограничений можно написать низкоуровневый код ЗауаЗсирь, 
но при этом возникнут проблемы вроде перечисленных ниже. 


е АР-интерфейс хмынеЕрБечиез + — основной механизм, применяемый для издания 
асинхронных запросов — следует скверной традиции требовать различный син- 
таксис для разных типов и версий браузеров. Для Пцегтее Ехр!огег 6 необходимо 
создать экземпляр объекта ХМЬНЕЕрВеаиаез® с использованием нестандартного 
синтаксиса, основанного на АсНуех. Другие браузеры поддерживают иной, хотя 
и более ясный синтаксис. 


® Этот довольно неудобный и многословный АРГСинтерфейс требует решения таких 
неочевидных задач, как отслеживание и интерпретация значений хеаду5такез. 


Как обычно, библиотека |Очегу привносит с собой простоту. Например, полный код, 
необходимый для асинхронной загрузки содержимого в элемент РОМ, выглядит следую- 
щим образом: 


$ ("#туЕ1етепе") .1оаа("/зоше/ихе1"); 


Код конструирует объект хмЬНЕ&рВечаез< (в независимом от браузера стиле), уста- 
навливает запрос, ожидает ответа и в случае успеха копирует разметку из ответа в ка- 
ждый элемент упакованного набора (те. пуЕ1етел®). Все очень просто! 


Ненавязчивый Уауа$ спрЁ и захват 


Каким же образом технология Адах вписывается в мир ненавязчивого ЗахаЗсиреё? 
Естественно, код Адах должен быть четко отделен от НТМГ-разметки, с которой он ра- 
ботает Также, по возможности. приложение должно проектироваться так, чтобы оно 
приемлемо работало даже при отключенном Зауа сре. Для начала создайте ссылки и 
формы, которые будут работать без ЗауаЭсир+. Затем напишите сценарий, который пе- 
рехватывает и модифицирует их поведение, когда поддержка ЗауаЗсйре доступна. 

Такой перехват и изменение поведения известен под названием захват (Ьуаск1л8). 
Некоторые даже называют это Д}ах-захватом (БЦах!15), поскольку обычно главная цель 
состоит в добавлении функциональности Адах. В отличие от большинства разновидно- 
стей захвата, эта не несет в себе ничего отрицательного. 


Захват ссылок 


Давайте вернемся к предыдущему примеру сетки и добавим к ней разбиение на стра- 
ницы. Сначала следует спроектировать поведение, не предусматривающее включенную 
поддержку ЗауаЗсире. Это довольно просто — добавьте необязательный параметр раде 
к методу действия бита () и выберите запрашиваемую страницу данных: 
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рефуафе сопзе 1пе Радеб1те = 3; 
рию11с У1емВези1 бипиа1 $ (1пЕ? раде) 
{ 


У1еирафа ["сихгепеРаде"] = раде 2? 1; 
Улемрата ["Сока1Радез"] = (30Е)МабЬ.Се11119(1.0 * поорфалирафа.Содре / РадебАте); 
уаг 1фепмз = поипса1пПафа.5К1р ( ( (раде 2? 1) - 1) * Раде51те) .Таке (Раде$1хе); 


тебаги У1ем (1емз); 


} 


Теперь можно обновить шаблон представления для визуализации ссылок на страни- 
цы. Здесь будет повторно использоваться вспомогательный метод НЕм1. РадеГ1иК$з (), 
созданный в главе 4 (чтобы сделать его доступным, обратитесь за инструкциями в раз- 
дел “Отображение ссылок на страницы” главы 4). После этого можно визуализировать 
ссылки на страницы: 


<в2>ТВБе 5еуеп Зои $ з</62> 
<а1у 19="зопии1 Е" 
<Гаф1е> 
<!-- ... оставить без изменений ... --> 
</фаю1е> 
Раде: 
<$%= Нёт1 . Раде А пКз ( (11) Узеирафа["сигкепЕРаде"], 
(11) Узеирафа ["Еофа1Радез"], 
1 => Огф.АсЕ1оп ("бои Ез", пем { раде =1 }) ) %> 
</94\> 
<р><1>ТЬ15$ раде депегафе@ аф <%= Рафет1е .Мом. ТоГопоТ1щеб капа () %></1></р> 


Для того чтобы видеть, когда работает (или не работает) А4ах, была добавлена вре- 
менная метка. Окно браузера при отключенной поддержке ЗахаЗсийре показано на 
рис. 12.10. 


ТР: раяе пененаёзе! си 14:27:37 


НИЕ 


Рис. 12.10. Простое поведение постраничного вывода серверной стороны 
(при отключенной поддержке Чама$ сир") 


Как видите, временные метки слегка отличаются, потому что каждая из трех страниц 
генерируется в разное время. Также обратите внимание, что оформление полосами строк 
сетки исчезло вместе с другими поддерживаемыми ]Очегу расширениями (это очевидно, 
поскольку поддержка ЗауаЗсирЕ отключена). Тем не менее, базовое поведение работает 


Выполнение частичных обновлений страницы 


Теперь, имея работающую реализацию без сценариев, наступило время обратиться к 
базовым возможностям Афах. Мы позволим посетителю перемещаться между страница- 
ми сетки без полного обновления страницы. При каждом щелчке на страничной ссылке 
соответствующая страница будет извлекаться и отображаться асинхронно. 
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Для выполнения частичного обновления страницы с помощью |@чегу перехватим 
событие с1аск ссылки, получим целевой ОВ! асинхронно, используя вспомогательный 
метод $.чее(), извлечем необходимую часть ответа и вставим ее в документ посред- 
ством .гертасенаен (). Несмотря на сложность формулировки, код, необходимый для 
применения ко всем ссылкам, соответствующим селектору. выглядит очень просто: 


$ ("#зопиаез А") .с11сК(ЕопсЕ1 оп () { 
$.аеЕ ($ (2113) .авЕх ("ргеЕ"), ЕарсЕ1оп (гезропзе) { 
$ ("зола ез") .гер1асей1ер ($ ("#зити1 $", гезропзе)); 
р; 
тебигл Еа15е; 


}); 


Обратите внимание, что обработчик с11ск возвращает +а1зе, не давая браузеру воз- 
можности выполнять традиционную навигацию на целевой ОЕ. ссылки. Также имейте 
в виду, что в с версией ]Очегу 1.3.2 связана одна причуда, которую может понадобиться 
обойти?, в зависимости от того, как структурирован НТМГ-документ:. Результат показан 
на рис. 12.11. 


7 нар иоса-оз65 2216 Ноль Зо. РЕ ВИЙ 
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Рис. 12.11. Первая попытка разбиения на страницы средствами Ах. 
Обратите внимание на ошибки 


Как видите, происходит что-то странное. Первый щелчок был обработан асинхронно 
(временная метка не изменилась}, хотя по какой-то причине исчезло оформление поло- 
сами. По второму щелчку страница даже не была извлечена асинхронно (зто видно по 
измененной временной метке). Что случилось? 

На самом деле все соверитенно закономерно: оформление полосами (и прочее поведе- 
ние, обеспечиваемое ]Очегу} добавляется только при первой загрузке страницы, поэтому 
не применяется ни к каким новым элементам, извлеченным асинхронно. Аналогично 
ссылки страниц обрабатываются только при первой загрузке страницы, поэтому второй 
набор ссылок страниц уже не имеет поддержки Аах. Вот и развеялась вся магия! 

К счастью, зарегистрировать поведение. усиленное ЗамаЗсирь, довольно легко несколь- 
ко другим способом, чтобы оно оставалось в силе даже при изменении модели РОМ. 


9 Элемент, который получается в ответ на вызов $ ("#з1463", кезропзе), не должен быть 
непосредственным дочерним элементом для <Боду>, иначе он не будет найден. Эта пробле- 
ма воэникает редко, но если понадобится найти элемент верхнего уровня, то следует при- 
менить код $ (гезропзе) .Е11фет ("Я91у#зп1 3"). 
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Использование функции 11уе () для сохранения поведения 
после частичных обновлений страницы 


Функция 11уе () из Очцегу позволяет регистрировать обработчики событий так, что 
они применяются не только к соответствующим элементам в начальной модели РОМ, 
но также и к соответствующим элементам при каждом обновлении ООМ. Это позволит 
решить проблему с пропаданием поведения, обеспечиваемого ]ДОчету. 

Начнем с выноса поведения строк таблицы в функцию по имени 1111а11хетае (): 


<8СЕ1рЕ фуре="Еехе/}ауазск1ре"> 


$ (ЕорсЕфоп () { 
110161а112еТаЪ1е(); 
// Поместить здесь остальные виды поведения (например, добавление 
// флажка Зром ре1оНез и захват ссылок на страницы) 


}); 


БорсЕЗоп 10161а112еТаЪ1е() { 
// Оформление полосами 
$ ("#зииЫ 3 Ег:еуеп") .аааС1азз ("а1+егпахе"); 
// Подтверждение удаления 


3 ("#3 Еогт[асЕ1от$=' /Бе1есетеет' |"). заба1ь (ЕопсЕЗ оп () { 
уаг 1ЕетТехе = $ ("1приф [паше=' 1{еп'] ", (013) .уа1(); 
тебакп сопЕ1ут("Аге уой зиге уоц мап® фо Челефе '" + 1ештехЕе + О 
}); 
} 
</зсефрЕ> 


Затем модифицируйте код захвата так, чтобы обработчик события шелчка регист- 
рировался с использованием 11уе (), и заставьте его вызывать 1014+1а11хетаЪ1е () по- 
сле каждого обновления РОМ: 


$ ("#зишиа $ А") .11уе ("с11сКк", ЕапсЕзов() { 
$.9е% ($ (713) .акЕк("ртеЕ"), Еопсетоп (хезропзе) { 
$ ("#1 ез").гер1асейт Ев ($ ("#зишиаез", тезропзе)); 
// Заново применить поведение строк таблицы 
1101Е1а112еТаЪ1е(); 


// Учесть состояние флажка $Вон Ведь 5 
1Е (1$ ("#Вез9ЪЕз") [0] .свескеа) 
$ ("#золшае$ Ва: оеь-свала (2)") .В1ае(); 
}); 
тебигп Еа15е; 
}); 


Этот код сохраняет все модифицированное поведение, включая поведение ссылок 
и отображение столбца Нещы$ (Высоты), независимо от того, сколько раз посетители 
будут переключаться между страницами. Текущее поведение приложения проиллюст- 
рировано на рис. 12.12. 


Совет. Если вы часто пользуетесь методом 11 те ()‚ то обратите внимание на подключаемый мо- 
дуль №еОиегу (р1ад1 плз.) чаегу.соп/рго- ес®/14+уедиеку), который делает зтот метод бо- 
лее мощным. При наличии этого подключаемого модуля предыдущий код несложно упростить, 
исключив метод 1п11Е1а11=еТаб1е () и просто объявив, что все поведение должно сохранять- 
ся независимо от изменений модели ВОМ. 
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Рис. 12.12. Разбиение на страницы с помощью Адах теперь работает правильно 


Дальнейшая оптимизация 


До сих пор получалось добавлять усовершенствования, предлагаемые Ах, даже не затрагивая 
код серверной стороны. Довольно впечатляюще: только представьте, насколько можно улучшить 
унаследованные приложения, просто добавив несколько операторов {биегу! При этом вносить 
изменения в код серверной стороны не понадобится. 


Однако в данный момент мы поступаем несколько расточительно в отношении пропускной спо- 
собности и времени процессора. Каждый раз, когда выполняется частичное обновление стра- 
ницы, сервер генерирует и передает по сети всю страницу целиком, даже несмотря на то, что 
клиента интересует только небольшая ее часть. Самый аккуратный способ справиться с этим в 
АЗРМЕТ МУС предусматривает вынесение обновляемой части полного представления в частич- 
ное представление по имени Зити1 ЕзСтта. После этого можно проверить, поступил ли текущий 
запрос через вызов Дах, и если да, визуализировать и вернуть только частичное представление. 
Например: 
рор11с АСЕ1орВезо1е бопиа 3 (106? раде) 
{ 

\1емрВафа ["сиггепЕРаае"] = раде ?? 1; 

\У1ерафа["Еофа1Радез"] = (10е)Мафр.Се111т9а (1.0%*топпфалпрафа .Сосре/Раде$1те); 

уаг 16ет$ = поппфа1праба.5К1р ( ( (раде ?? 1) - 1) * Радеб1те) .ТаКе (Раде$1те); 

1 (Ведаез®.Т5АдахВесиез®()) 

гебаги Узем ("бити Е$Сг1а", 16етз); // Частичное представление 
е1зе 
гебигп \У1ем (146ет5$); // Полное представление 

} 
Ючегу всегда добавляет НТТР-заголовок Х-Ведиезфеа-М1 ен, поэтому в методе действия мож- 
но использовать Ведоезь. тзАЗахВеаиез® () для различения обычных синхронных запросов и 
асинхронных запросов Ах. Кроме того, обратите внимание, что АЗРМЕТ МУС может визуализи- 
ровать одиночное частичное представление так же просто, как и полное представление. Готовый 
пример с примененной оптимизацией можно найти в загружаемом коде для зтой книги. 


Захват форм 


Иногда нужно захватить не просто ссылку, а целиком отправленную форму <гогп>. 
Вы уже видели, как это делается с помощью вспомогательного метода Адах.Вед1пЕокги: () 
из АЗРМЕТ МУС. Это означает, например, возможность построения формы. которая по- 
зволяет задать набор параметров поиска, выполнить отправку и отобразить результат 
без полностраничного обновления. Естественно, если поддержка ЗауаЗспире отключена, 
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то посетитель все равно должен получить результаты. но с традиционным полностра- 
ничным обновлением. Другим примером может случить применение формы для запро- 
са у сервера специфичных, отличных от НТМЕ данных, таких как текущие цены товаров 
в формате УЗОМ, без необходимости полностраничного обновления. 

Рассмотрим очень простой пример. Предположим, что на одну из страниц требу- 
ется добавить поле для просмотра биржевых котировок. В контроллере под названием 
ЗЕоскз может быть определен метод действия по имени сееОцосе (): 


руЮ11с с1аз$ ЗЕоскзСопего11ехк : Сопего11ех 
{ 
рую11с зёк1та берОцо{е (зЕт1па зупбо1) 
{ 
// Очевидно, что здесь можно сделать что-нибудь более полезное 
ЧЕ (зуйюо1 == "С00б") 
тебоагп "59999"; 
е1зе 
тебогп "боггу, ипкпомп зушро1"; // Неизвестный символ 


} 


В шаблон представления понадобится вставить следующую порцию разметки: 


<р2>56оскз</62> 
<% 51а (Нм .Вед1пРоги ("СефОцо%е", "5еосКкз")) { %> 
Зупро1 : 


<%= НЕш1 .ТехЕВох ("зупЬо1") $%> 
<1прае Еуре="забт1е" /> 
<зрап 14="гези13"></зрап> 
<% } %> 
<р><Р>ТИ1з раде депегафеая а <%= Рафетиле .Мом.ТогопаТ1 ее т1та() %></1></р> 


Теперь к форме очень легко добавить поддержку Ауах, как показано ниже (не забудь- 
те сослаться на }Очету и зарегистрировать этот код, чтобы он запускался после загруз- 
ки модели РОМ]: 


$ ("Рог [асЕ1оп$=' бефроцофе']") . забит (Еирсетол () { 
$ .розЕ ($ (213) .абег("асЕ1ор"), $ (+13) .зег1а112е(), ЕапсЕ1ол (гезропзе) { 
$ ("#хези1Е 5") .ПЕ1 (кезропзе); 
}); 
тебакп Еа1зе; 


$); 


Этот код находит любой злемент <Еоги>, который будет отправлять данные на ОБТ, 
заканчивающийся строкой сетОнцоте, и перехватывает его событие забн +. Обработчик 
выполнит асинхронный НТТР-запрос РОЗТ по ОЕ. исходного действия формы. отправ- 
ляя данные формы обычным образом (сформатированные для НТТР-запроса с помощью 
$ (2215) .зег1а11те()), и поместит результат в злемент <зрап> с идентификатором 
хези15. Как обычно, обработчик события возвращает Еа1зе ‚ чтобы форма не отправлялась 
традиционным способом. В резульгате получится поведение, показанное на рис. 12.13. 


На заметку! Этот пример не обеспечивает сколько-нибудь удовлетворительное поведение для 
клиентов с отключенной поддержкой Уауа$сир1. Для таких клиентов вместе с биржевой коти- 
ровкой заменяется вся страница. Чтобы обеспечить поддержку клиентов подобного рода, мож- 
но изменить сеебцоке () так, чтобы в случае возврата методом Бедиезе.ТзА] ахВестез® () 
значения Еа1зе НТМЁ-страница визуализировалась целиком. 
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Рис. 12.13. Захваченная форма вставляет результат в модель ВОМ 


Передача данных между клиентом 
и сервером в формате 3$0М 


Часто браузеру требуется передать более, чем простую единицу данных. Что если не- 
обходимо отправить объект, массив объектов или целый граф объектов? Для этой цели 
идеально подходит формат данных 4ЗОМ (ФауаЗсире Оес+ МофаНоп — объектная но- 
тация ЧауаЗс"! ре; мии. ] зоп.ога/) : он более компактный, чем предварительно сформа- 
тированный НТМГ. или ХМГ, и естественным образом распознается любым браузером, 
поддерживающим Зауаспре. В АЗРМЕТ МУС имеется специальная поддержка для пере- 
дачи данных /ЗОМ, а в |ОФчегу — для их получения. Верните иэ метода действия объект 
ЧзопВе$11+, передав ему для преобразования объект МЕТ, например: 


ручб11с с1азз 5босКраба 

{ 
рУ611с аес1та1 Ореп1паРи1се { чее; зет; } 
руЮ11с аес1мат С1оз1паРг1се { деф; зеф; } 
руБ11с зЕт1па Ваё1тоа { деё; зеф; } 

} 

руЮ11с с1азз ЗеоскзСопего11ег : Сопего11ех 


{ 
ру611с 9зопВези1е СеЕОцосе (зЕт1па зупфо1) 


{ 


// Здесь можно было бы извлечь некоторые реальные данные 
1Е (зушро1 == "6006") 
тебагп пем ФЧзопВези1е { Раба = пем З5босКк,афа { 
Ореп1паРг1се = 556.94М, С1оз1паРи1се = 558.20М, Ваф1та = "А+" 
}}; 


е1зе 
геёогп пи11; 


} 
Приведенный выше метод действия передает следующую строку: 
{ "Ореп1паРг1се": 556.94, "С1о31п9Рг1се":558.2, "Ваё1пд" : "А+" } 


Это формат представления объектов, принятый в ЗауаЗсир*. На самом деле он явля- 
ется исходным кодом ЗамаЗспре°. 


10 Точно так же пем { Ореп1поРк1се = 556.94М, С1озАпдрт1се = 558.20М, Ваё1юа = "А+" } 
представляет собой исходный код С#. 
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АЗРМЕТ МУС конструирует эту строку с использованием АР1-интерфейса .МЕТ под 
названием Зузеем. Мер .5сг1ре.5ех1а11таЕ1оп.Зауа$сг1реЗет1а11 тек, передавая ему 
объект $ЕосКРака. Зауа$сг1рЕ$ег1а11тег применяет рефлексию для идентификации 
свойств объекта и затем визуализирует его в формате УЗОМ. 


На заметку! Хотя объекты .МЕТ могут содержать как данные, так и код (т.е. методы), их /ЗОМ- 
представление включает только данные — методы опускаются. Простого способа для трансля- 
ции кода „МЕТ в код УамасирЕ не существует. 


На стороне клиента можно было бы извлечь строку 4ЗОМ, используя $.деё() или 
$.розе (), и затем разобрать ее в объект Зауа$спйре вызовом еуа1 () ". Однако сущест- 
вует и более простой путь: \Оцегу имеет встроенную поддержку извлечения и разбора 
данных 4ЗОМ с помощью функции под названием $.деез$0м(). Модифицируйте хпаб- 
лон представления следующим образом: 


<в2>8фоскз</Н2> 
% и51п9 (НЕт1 .ВедаоЕоги ("бебОоцофе", "$6осКкз")) { %> 
ЗушЬо1 : 
3= НЕм1.ТехЕВох ("зушбо1") %> 
<1прие вуре="зириа Е" /> 
<% %> 
<ЕаБ1е> 
<Ег><ЕЯа>Ореплта рг1се:</ЕАа><Еа 19="орепапаРг1се"></Е4></Ег> 
<Ег><Е9>С1оз1па ргасе:</Еа><Еа 14="с1оз1паРгасе"></А></Ег> 
<Ег><ЕЯ9>Вае1та:</Е9><6а 19="зкоскваЕ1та"></а></Ег> 
</Еар1е> 
<р><1>Тр15$ раде депегафеЯ аф <3= РафеТ1ше .Мом.ТоТопаТа те Е к4та() %></1></р> 


Затем измените код для отображения каждого свойства зкоскрафа в соответствую- 
щей ячейке таблицы: 


$ ("Еогм [асЕ1оп$=' Сеёоцофе!]") .забю1е (Еаосетоп () { 
$.че6530М ($ (613) .аЕЕх("асЕ1от"), $ (+115) .зег1а11те(), Еопсё1оп (збоскрафа) { 
$ ("#ореп1паРт1се") .ро1 (зсоскрафа.Ореп1паРт1се); 
$ ("#с1оз1паРх1се") .ретл (зЕоскрафа.С1оз1паРх1се) ; 
$ ("ЕэтоскВаф1тоа") .Па1 (зкоскрафа.Ва&1па); 
}); 
тефогр Еа1зе; 


}); 


В резульгате будет построено поведение, показанное на рис. 12.14. 


Совет. $.сее330М() — очень простая вспомогательная функция. Она может выдавать только 
НТТР-запросы СЕТ (но не РОЗТ) и не предусматривает никаких средств для обработки оши- 
бок передачи данных (например, если сервер вернет пи11). Если требуется более тонкий кон- 
троль, обратитесь к более мощной функции |Сиегу $.азах(). Она позволяет использовать 
любой НТТР-метод, поддерживает гибкую обработку ошибок, может управлять поведением кэ- 
ширования и также автоматически разбирать ответы /ЗОМ, если указано даъаТуре: "узоп" 
в качестве одного из необязательных параметров. Она также поддерживает протокол 4ЗОМ для 
междоменного извлечения данных /5ОМ. 


И Строку 4ЗОМ понадобится поместить в скобки, например, так; еуа1 ("(" + з6г + ")"). 
Если этого не сделать, возникнет приводящая в замешательство оптибка “ПауаНа ГаЪе?” (не- 
верная метка). 
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Рис. 12.14. Извлечение и отображение структуры данных /5ОМ 


При интенсивном использовании /ЗОМ в приложении сервер может восприниматься 
как коллекция веб-служб ]ЗОМ, а браузер — как механизм. полностью ответственный 
за построение пользовательского интерфейса. Это вполне корректная архитектура для 
современного веб-приложения (если предположить, что поддержка клиентов с отклю- 
ченным дауаЭсир{ не нужна). В этом случае получается выигрыит от мощи и прямоли- 
нейности АЗРМЕТ МУС, но полностью игнорируется механизм представлений. 


Выборка данных ХМЕ с использованием ]Оиегу 


По желанию во всех рассмотренных ранее примерах вместо формата 4ЗОМ можно 
использовать ХМГ. При извлечении данных ХМ. проще применять 1Оиегу-функцию 
$.а)ах() (вместо $.чеё()), потому что $.адах() позволяет использовать специальную 
опцию дафаТуре: "хш1", которая заставляет разбирать ответ как ХМГ. 

Сначала необходимо вернуть данные в формате ХМ! из метода действия. Например, 
модифицируйте предыдущий метод СееОноке (), как показано ниже, используя 
СопЕеп®Вези1 для установки корректного заголовка сопфепе-фуре: 


руБ11с СопеепЕВезо1Е беЕбцоке (56119 зупро1) 
{ 
// Вернуть некоторые данные ХМ в виде строки 
ЧЕ (зушБо1 == "С00С") { 
тебагп Сопееп® ( 
пех ХРоситеп® (пем ХЕ1етеп® ("Опцофе", 
пех ХЕ1ептепе ("ОрептпоРу1се", 556.94М), 
пем ХЕ1етепе ("С1оз1паРг1се", 558.20М), 
пеи ХЕ1етеле ("Ваф1па", "А+") 
)} -ТобЕетаа () 
‚ Зузбем.Мее.М1ще .Мед?аТуреМамез .Техе.Хи1.); 


} 


е1зе 
тебагп пи11; 


12 Здесь термин веб-служба используется для обозначения всего, что отвечает на НТТР- 
запрос, возвращая данные (например, метод действия, возвращающий 9зопВези1*, неко- 
торый ХМГ-код или любая строка). В АЗРМЕТ МУС любой метод действия можно рассмат- 
ривать как веб-службу. Если планируется работать со службой только с использованием 
запросов Адах, то нет причин связываться со сложностями протокола ЗОАР, файлов АЗМХ 
и описаний \/’ЗЬОГ. 
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Для параметра с006 этот метод действия произведет следующий вывод: 


<ОпоЕе> 
<Ореп1паРг1се>556.94</Ореп1паРх1се> 
<С1031п9Рг1се>558.20</С1оз1паРк1се> 
<ВаЕ1п9>А+</ВаЕ1поа> 

</биоЕе> 


Теперь нужно сообщить библиотеке |Очцегу, что получаемый ею ответ должен ин- 
терпретироваться как ХМГ, а не простой текст или 4ЗОМ. Разбор ответа в виде ХМЕ 
обеспечивает возможность использования самой }Омегу для извлечения данных из ре- 
зультирующего ХМГ-документа. Например, измените обработчик отправки формы из 
предыдущего примера следующим образом: 


$ ("Еокм [асЕ1оп$='СеЕОцофе'!]") . забит Е (ЕипсЕТоп () { 
$.адах ( { 

ии1: $ (713) .абег("асЕ1оп"), 

Туре: "СЕТ", 


Чата: $ (201$) .зег1а117е(), 
аафаТуре: "хи1", // Инструкция разбирать ответ как ХМГРосомере 
зиссезз: ЕапсЕтоп (гезо1Хи1) { 
// Дополнительные данные из ХМ .росомепе с использованием селекторов )Очегу 
уаг ореп1па = $ ("Ореп1поаРг1се", гези1ЕХи1).кехе(); 
уаг с1оз1па = $ ("С1031п9Рг1се", гези1&Хи1).Еех®(); 
х\ахг каб1та = $("Ваф1та", геза1ЕХи1) .Бехе(); 
// Использовать данные для обновления модели РОМ 
$ ("#ореп1паРг1се") „ре (ореп1 па); 
$("#с1оз1паРг1се") .РЕт1 (с10311п9); 
$ ("+зЕоскВаф1та") .ВЕт1 (гаф1поа); 
} 
}); 
тебагп Еа1зе; 


}); 


Теперь приложение ведет себя точно так же, как было при отправке данных в фор- 
мате 3ЗОМ (рис. 12.12), за исключением того, что данные передаются в виде ХМГ. Тем 
не менее, большинство веб-разработчиков предпочитают иметь дело с форматом УЗОМ, 
поскольку он более компактный и читабельный. К тому же работа с ЗЗОМ означает 
уменьшение объема код, который придется писать, так как АЗРМЕТ МУС и ]Очегу обес- 
печивают более аккуратный синтаксис для генерации и разбора. 


Анимация и другие графические эффекты 


До недавнего времени большинство веб-разработчиков благоразумно избегали за- 
бавных графических эффектов наподобие анимации, кроме как при использовании 
АаоБе НазЬ. Причина в том, что средства анимации ОНТМГ, примитивны (по меньшей 
мере) и никогда не работают достаточно согласованно в разных браузерах. Всем нам не 
раз доводилось наблюдать чудовищно любительские “специальные эффекты” ОНТМГ, 
которые работали из рук вон плохо. Настоящие профессионалы старались избегать их. 

Однако с появлением в 2005 г библиотеки эсирЕ.асшо.из стали возможными удоб- 
ные и приятные визуальные эффекты, которые корректно работают во всех популярных 
браузерах, и эта тенденция изменилась’. 


13 Библиотека зст1ре.аси1о .аз основана на 4 ауаЗсирЕ библиотеке Ргообуре, которая во мно- 
гом обладает теми же возможностями, что и }Опегу. Более подробные сведения доступны 
по адресу БЕЕр://зст1рЕ.аси1о.15/. 
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Библиотека }Оцегу также не отстала в зтом отношении: в ней реализованы базовые 
эффекты вроде постепенного появления и исчезновения, плавного перемещения, сжа- 
тия и растягивания злементов и тп., причем все это доступно через краткий и простой 
АРГинтерфейс. При разумном использовании с помощью этих средств можно добавить 
профессиональные штрихи к интерфейсу веб-приложения. 

Самое замечательное то, насколько легко это делается. Достаточно линь получить 
упакованный набор и применить один или более вспомогательных методов “эффектов”, 
таких как .ЕадеТп() или .Еадебч+ (). Например, возвращаясь к предыдущему примеру 
с биржевыми котировками, можно было бы записать так: 


$ ("Еогм [асЕ1ор$='СефОцове']") . заЫиа (ЕопсЕтоп () { 
$.чеЕ95$0М ($ (2213) .абЕх("ас®1от"), $ (1015) .зегфа112е(), РарсЕфоп (зфоскрафа) { 
$ ("#ореп1паРк1се") .Вт1 (зЕосКкБафа.Ореп1поаРг1се) .В14е().Еааетп(); 
$ ("#с1оз1паРгасе") .В 1 (зкоскрафа.С1о51паРх1се) .В14е().Еа4етп(); 
$ ("#зЕоскВаЕ1та") .БЕт1 (зсосКкрафа.ВаЕ1па) .Н14е().ЕаЧетп(); 
}); 


тебаги Еа1зе; 


}); 


Обратите внимание на необходимость сокрытия элементов (например, с помощью 
ртае ()) перед тем постепенным их появлением. Теперь данные биржевых котировок 
появляются в представлении постепенно, а не внезапно. предполагая, что браузер под- 
держивает свойство непрозрачности. 

Помимо готовых эффектов появления и перемещения, библиотека |Очегу предлагает 
мощный метод анимации общего назначения под названием .ап1пате()}. Этот метод 
позволяет плавно анимировать любые числовые стили С$$ (ит ан, петавь, ЕопЕ$12е 
итн.), например: 


$ (зе|1есбог) .апипаге ( {Еопе51=е : "10ещ"}, 3500); // Эта анимация займет 3,5 секунды 


Для выполнения анимации определенных нечисловых стилей С$$ (например, цвета 
фона, чтобы получить известный в \Ь 2.0 эффект постепенного затухания желтого) 
понадобится получить официальный подключаемый модуль }Очегу под названием Союг 
Апйтайопт$ (Пр: //р1ао1п$ .3)ачеку. сош/ргозесь/со1от). 


Предварительно построенные 
графические элементы |@иегу Ц 


Десятилетие назад, когда платформа АЗРМЕТ \еБЕогпаз пока только задумывалась, 
предполагалось, что веб-браузеры слишком непредсказуемы. чтобы обрабатывать ка- 
кого-либо рода сложное взаимодействие клиентской стороны. Вот почему, например. 
исходный элемент выбора даты \МеБЕогиа$ <азр:са1епдах> визуализирует себя в виде 
простой НТМГ-разметки, вызывая полный цикл обмена с сервером всякий раз, когда его 
разметка нуждается в изменении. В те времена это предположение было в значитель- 
ной мере верным, но сегодня оно определенно устарело. 

В наши дни код серверной стороны более сосредоточен на реализации прикладной 
и бизнес-логики, визуализируя простую НТМГ.-разметку (или даже в основном выпол- 
няя функции веб-службы УЗОМ или ХМЦ. Это дает возможность построить развитую 
интерактивность на стороне клиента, выбирая любое из множества доступных средств 
создания пользовательских интерфейсов, независимых от платформы, как с открытым 
исходным кодом, так и коммерческих. Например, существуют сотни чисто клиентских 
элементов управления для выбора даты, которые можно использовать, включая встро- 
енные в библиотеки ]Очцету и АЗРМЕТ ААХ. Поскольку они выполняются в браузере, 
они могут адаптировать свое отображение и поведение к поддерживаемому браузером 
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АР-интерфейсу, который обнаружат во время выполнения. Идея серверного элемента 
управления для выбора даты теперь устарела; очень скоро то же самое можно будет ска- 
зать о сложных табличных элементах управления серверной стороны. Мы наблюдаем 
все более четкое разделение ответственности между серверной и клиентской стороной. 

Проект /Фцчегу [Л (Бер: //о1.) чцегу .сом/), построенный на основе }Очегу, предла- 
гает хороший набор многофункциональных злементов управления, которые отлично 
работают с АЗРМЕТ МУС, включая меню, средства выбора дат, диалоговые окна. пол- 
зунки и панели с вкладками. В нем также доступны абстракции, помогающие создавать 
межбраузерные интерфейсы с возможностью перетаскивания. 


Пример: сортируемый список 


Функция .зогфаб1е() из библиотеки ]Оцегу ЧТ позволяет организовать сортиров- 
ку с перетаскиванием для всех дочерних злементов по отношению к заданному. Имея 
представление шаблона, строго типизированное для ГЕпощехаь1е<Монпта1пти+о>, сор- 
тируемый список организовать несложно: 


<5>0012=:</Б> Сап уой риё Безе попипба1из$ 1п огдег оЕ НетойЕ (фа11езе Е1хзе)? 
<алу ла="зопи1ез"> 
<% ЕогеасВ (уаг поппеа1п 1п Моае1) { $%> 
<а1у с1азз="тшоипфа1т"><%= поипфа1т.Маще %></а1у> 
<% } %> 
</алу> 
<зск1фре> 
$ (ЕапсЕтол () { 
$ ("зонт") .зогфарте (); 
}); 
</зск1рЕ> 


На заметку! Чтобы приведенный выше код работал, понадобится загрузить и установить ссылку 
на библиотеку {Фиегу Л. Зайдите на веб-сайт проекта Пер: //и1.3)ааегу. сом/ и щелкните 
на ссылке Вийа сизют домилюаа (Построить специальную загрузку) для получения елинст- 
венного файла . - <, который включает модули Л Соге и бочаые (и другие модули, которые вы 
решили использовать}. Добавьте полученный файл в папку /Зск1рез и установите ссылку на 
него из мастер-страницы или страницы представления АЗРХ. 


Это позволит посетителю перетаскивать элементы а1 у, размещая их в другом поряд- 
ке, как показано на рис. 12.15. 
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Рис. 12.15. Функция .зохЕаБе () из библиотеки {Оиегу Ш! в действии 
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Посетитель может просто перетаскивать рамки с элементами вверх и вниз, и каж- 
дый раз, отпуская кнопку мыпшти, они будут выравниваться по отношению к своим но- 
вым соседям. Чтобы отправить обновленный отсортированный список обратно серверу, 
добавьте форму <Еотт> с кнопкой отправки и перехватите событие эзибт1*: 


% из1иа (НЕ .Вед1иКокт()) { %> 
<$= Ныи1Т.Наааеп ("стозепОтгаехг") %> 
<1приЕ вуре="заыт1е" уа1ае="ЗабтаЕ уойг апзмек" /> 
<$ } 3%> 
<зсг1ре> 
$ (Еоосетоп () [ 
$("Еогш") . зоба (Епасетоп () { 


уаг сигкепеОтаех = ""; 
$("#зопите5 Ч1у.поппеа1и") .еась (Еаасе1оп() { 
соггепеОгаек += $ (513) .6ехе() + "|"; 


}); 
$ ("#спозепОтаег") .уа1 (сагкеп®Огает) ; 
}); 
}); 
</зсг1рЕ> 


В момент отправки формы обработчик события зоЪи1е заполняет скрытое поле 
снозепОгдег строкой. которая содержит названия гор, разделенные вертикальной чер- 
той, в соответствии с текущим порядком сортировки. Эта строка, естественно, отправ- 
ляется серверу как часть данных в НТТР-запросе РОЗТ\. 


Реализация проверки достоверности 
на стороне клиента с помощью |@иегу 


Существуют сотни подключаемых модулей для библиотеки }Очету. Один из наиболее 
популярных — }Оцегу.МаНАа{е — позволяет добавлять к формам логику проверки дос- 
товерности на стороне клиента. Для его использования понадобится загрузить файл 
} ачегу.уа11За%е.)$ по адресу р1191п5 .)] даегу.сом/ргодес®/уа11да%е и поместить 
этот файл в папку /Зсг1рЕз. Далее следует сослаться на него в дескрипторе <5 сг1ре> 
ниже основного дескриптора <зсг1рЕ> со ссылкой на ]Очегу. 

Предположим, что имеется следующая форма для ввода данных: 


<в2>Р1едае Мопеу Ко Оиг Сашра1ди</В2> 
<р>и1ЕН уопк Бе]1р, ме сап егадасаке &Не &1%4;5111К&9%; ад Еогечег.<р> 
<% и51п9 (НЕ1 .ВедтиЕоги()) $> 
<алу> 
Уосиг паше: <%= Неи1т.ТехфВох ("р1едде.баррогфегМате") %> 
</алу> 
<алу> 
Успг епа11 ад@гезз: <%= НиТ .ТехьВох ("р1еаде .Зиррог®етЕта11") $> 
</алу> 
<а4у> 
Апопие со р1еаде: $<%= Неи1.ТехфВох ("р1еаде.Атоцие") %> 
</91у> 
<р><1прие всуре="зиыи1е" /></р> 
<$ } %> 


14 В качестве альтернативы можно использовать функцию .зогба Бе ("5ет1а112е") из биб- 
лиотеки 1Фиегу ОТ, которая визуализирует строку, представляющую текущий порядок сор- 
тировки. Однако на самом деле это менее удобно, чем ручной подход, продемонстрирован- 
ный в примере. 
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Для того чтобы поручить модулю ]Оцегу.МаНаае проверку достоверности формы на 
стороне клиента, необходимо указать правила и дополнительно определить специаль- 
ные сообщения об ошибках: 


<зсг1рЕ Буре="Еехе/)ауазскаре"> 
$ (Еопсетоп () { 
$("Еогм") .уа11За*е ({ 

еггогС1аз5: "Е1е1Ча-уа11Зас1оп-еггохг", 

го1ез: { 
"р1еаде.ЗиррогкегМате": { гедилгей: 6гие, тахлепс®Н: 50 }, 
"рТеаде . ЗиррогкегЕма11": { геди1кеЯ: ские, ета11: &кие }, 
"р1еаде.Атоипе": { геда1гей: Екие, шли: 10 } 

}, 

пеззадез: { 
"р1еаде.Атоние"; { пла: "Соше оп, уси сап длуе а® 1еаз® $10.00!" } 


}) 
р; 
</зск1р®> 


Теперь пользователь не сможет отправить форму, пока введенные им данные не 
будут соответствовать заданным условиям. Сообщения об отибках будут появляться 
(рис. 12.16) и исчезать по мере устранения пользователем соответствующих проблем. 
За дополнительной информацией о множестве правил и опций, поддерживаемых ]Оиегу. 
УаПаае, обращайтесь к документации по адресу досз .)ааегу.сов/ Р1191п5/Уа11да1оп. 


38 дек - НИвглеЕ Ехоюгег 


Вр: Посаозе534аТ: 


ЗУ усе Вейр. уе сап ега@сае Ше <ББок> {ад фохеует. 


У сш ваше; Зее 


Е Ы 


Уонг ешай а44гезс; Из а заст Р!едье евиег а сэБа стай весе, | 
 Атошле о реаде: 55 00 Сояле св, зо са ие а еаи 520.00! 
Г Барт биеку 


у щетина 


й_ 


| 
| 
} 


Рис. 12.16. Проверка достоверности на стороне клиента препятствует отправке формы 


Внимание! Проверка достоверности на стороне клиента — это не что иное, как удобное поведение 
для пользователей. Гарантировать, что правила клиентской стороны будут соблюдены, нельзя, 
поскольку пользователи могут просто отключить поддержку ЧауаЗсИрЕ в своих браузерах или 
обойти проверку другим способом, как описано в главе 13. Чтобы гарантировать соблюдение 
правил, проверка достоверности также должна быть реализована и на стороне сервера. 


Такой подход хорошо согласуется с любыми стратегиями проверки достоверности 
серверной стороны, которые рассматривались в предыдущей главе. Недостаток его со- 
стоит в том, что приходится описывать одни и те же правила проверки достоверности 
по два раза: один раз на сервере, на языке С#, и второй — на клиенте, на Зауа$спри. 
Не правда ли, было бы здорово, чтобы правила клиентской стороны выводились авто- 
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матически из правил серверной стороны? В главе 11 описан способ реализации этого 
за счет декларативного представления подмножества правил на стороне сервера в виде 
атрибутов. Это сокращает рабочую нагрузку и позволяет избежать нарушения принци- 
па “не повторяться”. 


Подведение итогов по |Оиегу 


Если вы впервые увидели }Очегу в действии, то есть надежда, что ваще представле- 
ние о Зауа$сп!рЕ изменится. Создание изощренного взаимодействия на стороне клиен- 
та. которое поддерживается во всех популярных браузерах (с незначительными ухуд- 
шениями при отключенной поддержке ЗауаЗ ср — задача непростая, но здесь все по- 
лучается естественным образом. 

]@чегу хорошо работает с платформой АЗРМЕТ МУС, потому что последняя не вме- 
шивается в структуру НТМГ-разметки или в идентификаторы элементов, и здесь не 
происходит автоматических обратных отправок, которые нарушили бы динамически 
созданный пользовательский интерфейс. Подход МУС, предполагающий возврат к ос- 
новам, здесь в действительности окупается. 

{Очегу — не единственная популярная библиотека ЗауаЗспрЕ с открытым исходным 
кодом (хотя похоже, в настоящее время она завоевала максимум сторонников). Можно 
также попробовать библиотеки Ргофофуре, МооТоо!$, Ооо, УаВоо Чзег пиегасе 146гагу 
(0) или Ех 3$ — все они прекрасно сочетаются с АЗРМЕТ МУС. причем допускается 
одновременное использование более одной из них. Каждая библиотека характеризуется 
своими сильными сторонами: так, например, Ргоюбуре расширяет объектно-ориентиро- 
ванные средства программирования ЗауаЗсп!рь, в то время как Ех 4$ предлагает не- 
вероятно многофункциональные и красивые графические элементы пользовательского 
интерфейса. Рою поддерживает аккуразный АРГинтерфейс для автономного хранили- 
ща данных на стороне клиента. И, конечно же, все эти проекты имеют привлекатель- 
ные веб-сайты в стиле \№Ь 2.0 с массой кривых, градиентов и кратких высказываний. 


Резюме 


В этой главе были показаны два основных пути реализации функциональности Адах 
в приложении АЗРМЕТ МУС. Сначала рассматривались встроенные в АЗРМЕТ МУС 
вспомогательные методы Адах.*, которые очень легко использовать, но которые обла- 
дают ограниченными возможностями. Затем был дан обзор библиотеки ]Фиегу, которая 
является невероятно мощной, но требует хороших знаний ЗауаЗ с" ре. 

К этому моменту вы изучили почти все средства МУС ЕгатехмотК. Осталось еще по- 
нять, каким образом АЗРМЕТ МУС вписывается в более общую картину, в частности, 
как развернуть приложение на реальном веб-сервере и как интегрировать его с основ- 
ными средствами платформы АЗРМЕТ. Рассмотрение этих вопросов начнется в следую- 
щей главе, где будут описаны ключевые моменты безопасности, о которых следует знать 
каждому разработчику веб-приложений с помощью АЗРМЕТ МУС. 


ГЛАВА 13 


Безопасность 
и уязвимость 


Н е обладая солидным знанием проблем безопасности веб-приложений на уровне 

запросов и ответов НТТР, вряд ли можно достигнуть многих высот в веб-разра- 
ботке. Все веб-приложения потенциально уязвимы для известного множества атак, в 
том числе межсайтовыми сценариями (сгоз8-зКе зсирцоя — Х$5). межсайтовой поддел- 
кой запросов (сгоз8-5Не гециезЕ Когаегу — СЗВЕ) и внедрением кода ЗСТ, (ЗОТ, пцесноп). 
Однако этим угрозам можно противостоять, если хорошо понимать их суть. 

К счастью, платформа АЗРМЕТ МУС не привносит с собой существенно новые риски 
относительно безопасности. Для нее характерен простой и ясный подход к обработке 
НТТР-запросов и генерации ответов НТМГ, так что оснований для каких-либо опасений 
не должно быть. 

В начале этой главы будет показано, насколько легко конечным пользователям ма- 
нипулировать НТТР-запросами (например, модифицируя соове-наборы или скрытые 
либо отключенные поля форм), что должно способствовать более глубокому пониманию 
проблем безопасности веб-приложений. После этого вы узнаете обо всех наиболее веро- 
ятных направлениях атак, включая то, как они работают и каким образом применяют- 
ся к АЗРМЕТ МУС. Вы научитесь блокировать каждую из этих атак, а также исключать 
их еще на этапе проектирования. В завершение главы рассматривается несколько во- 
просов безопасности, специфичных для МУС Егаше\отЕ. 


На заметку! Эта глава посвящена основам безопасности веб-приложений. Здесь не рассматри- 
ваются средства контроля доступа, такие как пользовательские регистрационные записи и 
роли — за сведениями об этом обращайтесь к главе 9, где описывается фильтр [Аневог1 те], 
икглаве 15, в которой рассказывается о базовых средствах аутентификации и авторизации 
платформы АЗР МЕТ. 


Все вводимые данные могут быть подделаны 


Прежде чем приступить к рассмотрению “реальных” векторов атак, давайте прой- 
демся по целому классу простейших, тем не менее, широко распространенных уязви- 
мостей. Их можно было бы охарактеризовать одной фразой: не доверять пользователь- 


скому вводу. 


Глава 13. Безопасность и уязвимость 445 


Ниже перечислены категории пользовательского ввода, который не заслуживает 
доверия. 
® Входящие ОН. (включая значения Ведиез® .Опекуб&г1ио []). 
® Данные форм (те. значения Ведиезс.Еоги[], в том числе скрытые и отключен- 
ные поля). 
® Сооще-наборы. 


® Данные из других НТТР-заголовков (подобных Ведчиез& .ОзегАдепе и Кеаиез+. 
Ох1ВеЕеггехт). 


В общем случае пользовательский ввод включает все содержимое любого входящего 
НТГР-запроса (протоколу НТТР посвящена врезка “Краткое описание работы протокола 
НУТР”). Это вовсе не означает, что следует отказаться от использования соое-наборов 
или строки запроса; это значит лить, что при проектировании приложения безопас- 
ность не должна полагаться на то, что пользователям будет невозможно (или трудно) 
манипулировать данными соое-наборов или скрытых полей формы. 


Краткое описание работы протокола НТТР 


Разработчик веб-приложений, регулярно читающий специальную литературу, должен хорошо знать, 
что собой представляют НТТР-запросы: как выглядят запросы СЕТ и РОЗТ, каким образом пере- 
даются соое-наборы и как в действительности происходит взаимодействие между браузерами и 
веб-серверами. В качестве напоминания ниже приведены краткие сведения о протоколе НТТР 


Простой запрос СЕТ 
Когда веб-браузер выполняет запрос к УВЕ ул . ехашр1е . соп/ра В /гезопгсе, производит- 
ся поиск {Р-адреса элги .ехапшрт1е . сом в системе ОМ$, открытие ТСР-соединения через порт 80 
и отправка следующих данных: 


СЕТ /раеВ/тезосксе НТТР/1.1 

Нозе: ими. ехапр]1е . сот 

[пустая строка] 

Обычно также передаются некоторые дополнительные заголовки, но выше показано все, что 
строго необходимо. Веб-сервер отвечает примерно так: 


НТТР/1.1 200 ОК 
Рафе: Меа, 19 Маг 2008 14:39:58 СМТ 
Зегуег: М1скозоЕ®-Т1$/6.0 
Соп$еп&-Туре: тех®/р1а1и; свагзее=оЕ-8 
<НТМЬ> 

<ВоруУ> 

Т зау, 1015 15 а <1>Е1пе</1> меЬ раде. 

</вору> 

</нНтмь> 
Запрос РО$Т с соое-наборами 


Запросы РОЗТ значительно сложнее. Основное их отличие в том, что они могут нести рабочую 
нагрузку (рауюаа), которая следует за НТТР-заголовками. Ниже приведен пример, на этот раз 
включающий чуть больше распространенных НТТР-заголовков: 


РОЗТ /расБ/гезоигсе НТТР/1.1 

Ноз®: мми.ехашр1е . сом 

Озег-Адепе: Мо711]а/5.0 Е1лгеЕох/2.0.0.12 
Ассерф: сехе/хи1, арр11сае1оп/хи1, */*;а=0.5 
СопсепЕ-Туре: арр11са®1оп/х-имм-Еоги-ог1епсодеа 
ВеЕегег: ВЕфр://мия.ехатр1е .соп/ зопераде . 1 
Соптеп-церваеВ: 45 

Соок1е: Соок1е1=ЁР1х5®Уа1ае; Соок1е2?=бесопауа1Тае 
Е1хз©РоттЕ1е19=уа1ое1&зесопЯЕотиЕ1ле1Ч=уа1ое2 
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Рабочая нагрузка — это набор пар “имя/значение”, которые обычно представляют все элементы 
управления <ТМРОТ> дескриптора <ЕОВМ>. Как видите, сооКе-наборы передаются в виде раз- 
деленных точками с запятой пар в единственном НТТР-заголовке. 


Обратите внимание, что строго контролировать время действия сооКе-набора нельзя. Несмотря 
на то что есть возможность установить рекомендуемую дату устаревания сооКе-набора, заста- 
вить браузер соблюдать эти рекомендации не удастся (браузер может продолжать отправлять 
данные сооКе-набора сколь угодно долго). Если сроки действительности сооке-наборов являет- 
ся важным аспектом модели безопасности, потребуются средства их соблюдения. В главе 11 был 
приведен пример применения для этого кодов НМАС. 


Подделка НТТР-запросов 


Наиболее базовый, низкоуровневый уровень отправки произвольного НТТР-запроса 
состоит в использовании ОО$-программы +е1пеё вместо браузера". Откройте окно ко- 
мандной строки и подключитесь к удаленному хосту через порт 80 с помощью команды 
се1пеЕ мми.ехапр1е.сом 80. После этого можно ввести НТТР-запрос, завершив его 
пустой строкой, и в командном окне в качестве ответа появится результирующая НТМТ.- 
разметка. Это доказывает, что кто угодно может отправить веб-серверу любой набор 
заголовков и значений соове-наборов. 

Однако набрать целый НТТР-запрос вручную и не допустить при этом ошибки не всегда 
просто. Намного легче перехватить действительный запрос веб-браузера и затем модифи- 
цировать его. В этом поможет Насег — блестящий и совершенно легальный инструмент 
отладки от МсгозоЁ. Он работает как локальный веб-прокси, так что браузер посылает 
свои запросы через Р14@ег. не напрямую в Интернет. ЕА@ег может перехватывать и при- 
останавливать любой запрос, отображая его в дружественном графическом интерфейсе 
и позволяя редактировать его содержимое перед отправкой. Подробную информацию о 
загрузке и установке инструмента РАег ищите по адресу мутят. Етаа1егоо1 .сош/. 

Например, если на плохо спроектированный веб-сайте доступ к средствам админи- 
стрирования контролируется посредством соое-набора ТзАдт1 и (со значениями &гие 
и Еа1 зе), можно было бы легко получить административный доступ, просто изменив в 
На@ег значение соове-набора любого запроса (рис. 13.1). 


Серу опы аше 


Реточе Нааде | , 


т 
Зизет Неадаг Любая | 


Рис. 13.1. Применение НЧег для редактирования активного НТТР-запроса 


' По умолчанию в ОС Уйтао Уа и МИпаомз 7 программа $е1пе+* не устанавливается. 
Чтобы установить ее. щелкните на значке Программы и компоненты в панели управления. 
В открывшемся окне щелкните на ссылке Включение или отключение компонентов МАП ом и 
затем отметьте флажок Клиент Тепет. 
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Аналогичным образом можно было бы отредактировать данные полезной нагрузки в 
запросе РОЗТ, чтобы не выполнялась проверка достоверности на стороне клиента или 
отправлялась поддельная информация Ведчиезе.Ох1ВеЁеггег. Хотя ЕАег является 
мощным универсальным средством для манипуляций запросами и ответами НТТР, су- 
ществуют и более простые способы редактирования определенных вещей. 


» Егерид — замечательное бесплатное средство редактирования для браузера 
Етгеюх, особенно незаменимое для тех, кто пишет код Чауазсй ре. Одна из многих 
вещей, которую можно делать с его помощью — это просматривать и модифици- 
ровать объектную модель документа (РОМ) любой загруженной в браузер страни- 
цы. Разумеется. зто означает возможность редактирования значений полей, не- 
зависимо от того, являются они скрытыми, отключенными или подверженными 
проверке достоверности посредством ЗауаЗсйре. Аналогичные инструменты дос- 
тупны и для Н\егпеё Ехр!огег”, но ЕгеБиз — один из лучших. 


» \УеБ Оеаорег ТооФаг — еще один подключаемый модуль для ЕпеЮх. Помимо про- 
чего, он позволяет просматривать и редактировать значения соое-наборов и 
мгновенно делать все поля формы доступными для записи. 


Если не относиться к каждому отдельному НТТР-запросу с подозрением, можно от- 
крыть злонамеренному или любопытному посетителю доступ к чужим данным или по- 
зволить выполнять неавторизованные действия, просто изменяя строку запроса, дан- 
ные формы или данные соове-набора. Ваша задача состоит не только в том, чтобы 
предотвратить манипуляции запросами или ожидать, что АЗРМЕТ МУС сможет сделать 
зто за вас, но и в том, чтобы обеспечить проверку легитимности операций зарегистри- 
рованного пользователя. За более подробными сведениями о настройке регистрацион- 
ных записей пользователей и ролей обращайтесь в главу 15. Те редкие случаи, когда 
необходимо предотвратить манипуляции запросами, рассматриваются в примере при- 
менения кодов НМАС в главе 11. 

Давайте теперь рассмотрим “реальные” векторы атак, превалирующих в наши дни, 
и способы противостояния им в приложениях МУС. 


Межсайтовые сценарии и внедрение НТМЁ-кода 


Выше было показано, как злоумышленник может посылать непредвиденные НТТР- 
запросы непосредственно на сервер. Более изощренная стратегия атак заключается 
в том, чтобы заставить браузер другого посетителя посылать непредвиденные НТТР- 
запросы вместо себя, обходя отношения идентичности, уже установленные между при- 
ложением и жертвой. 

Межсайтовые сценарии (Х$$) — это одна из наиболее известных и распростра- 
ненных проблем безопасности. затрагивающих современные веб-приложения. На мо- 
мент написания книги она позиционировалась проектом ОМАЗР (Ореп \\еЪ АррНсаНоп 
ЗесигНу Рго]есё — Открытый проект безопасности веб-приложений) как главная про- 
блема безопасности веб-приложений?, а в выпущенном компанией Зутатес в 2007 г. 


2 Одним из таких инструментов является циегиеё Ехрюгег Оеуеюрег Тоофаг, доступный по 
адресу ВЕЕр: //Е1пуит1 . сом/2ухаа52 или ВЕЕр: / /мии.и1скозоЕЕ . сом/ 9оип10а95 /дефа115. 
азрх? Еап11у19=е59с3964-6729-4511-553е-295е19091038&491зр1ау1апа=еп. (Не следует пе- 
реоценивать значение чистых ОРГ. В действительности важны только корректные иденти- 
фикаторы СОТО.) 


3 Список 10 важнейших угроз безопасности доступен по адресу ик .омазр.ота/лидех .рЮр/ 
Тор _10_2007. 
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отчете “Пиегпеё Зесигу ТЬгеа& КерогЁ” (Отчет по угрозам безопасности в Интернете) 
было указано, что Х55 составляет 80% всех документированных угроз. 

Теория проста: если злоумышленник может заставить сайт вернуть посетителям 
некоторый произвольный ТауаЭсире-код, то его сценарий может захватить контроль 
над сеансами браузеров этих посетителей. Злоумышленник может затем динамически 
модифицировать РОМ-модель, полностью изменив веб-сайт либо аккуратно внедрив 
другое содержимое, а также может немедленно перенаправлять посетителей на какой- 
то другой веб-сайт. Вдобавок злоумышленник может молча перехватывать конфиден- 
циальные данные (пароли или информацию кредитных карт) или, пользуясь доверием 
посетителей к домену, обманным путем заставить их установить вредоносное НО на 
свои компьютеры. 

Ключевой фактор заключается в том, что если злоумышленник заставит ваш сер- 
вер вернуть сценарий самого злоумьниленника другому посетителю, то зтот сценарий 
будет запущен в контексте безопасности вашего домена. Добиться этого можно двумя 
способами. 


®_ Постоянный способ, когда злоумьниленник набирает тщательно сформированный 
вредоносный ввод в некотором интерактивном средстве (таком как доска объяв- 
лений), в надежде, что вы сохраните его в базе данных и затем раздадите другим 
посетителям. 


® Непостоянный, или пассивный способ, когда злоумышленник отыскивает путь от- 
правки вредоносных данных в запросе к вашему приложению и заставляет при- 
ложение возвращать эти данные обратно в ответе. После этого злоумышленник 
находит способ заставить жертву выполнить такой запрос. 


На заметку! Браузер н\егле{ Ехр/огег 8 пытается обнаружить и блокировать ситуации, когда веб- 
сервер выдает эхо-ответ (или отражает) в виде кода дама сИрЕ немедленно после межсайтово- 
го запроса. Теоретически это должно снизить вероятность пассивных атак ХЗ$. Однако это не 
исключает риска: технология еще не проверена в реальных условиях, она не блокирует посто- 
янных атак Х$$, да и не все посетители будут пользоваться тегпе{ Ехрюгег 8. 


Чтобы ознакомиться с менее распространенными способами выполнения пассивных 
атак Х55, исследуйте разделение НТТР-ответа, закрепление (рилпн15) О№$ и целое мно- 
жество междоменных ошибок браузеров. Такие атаки относительно редки, и произво- 
дить их намного труднее. 


Пример уязвимости Х$$ 


При реализации корзины для покупок в приложении Зройоге (см. главу 5) мы 
тщательно избегали решений, порождающих уязвимость Х$$5. Ранее об этом не упоми- 
налось, но наступило время посмотреть, что могло пойти не так. 

Метод действия Тпаех () контроллера саг+Сот%го11ех принимает параметр по име- 
ни гебикпОг1 и копирует его значение в У1ехПРата. Затем его шаблон действия исполь- 
зует это значение для визуализации простого дескриптора ссылки, который отправляет 
посетителя обратно к просматриваемой ранее категории товаров. В первоначальном ва- 
рианте в главе 5 дескриптор ссылки визуализировался следующим образом: 


<а вхеЁ="<%= У1емПафа["гебохпОг1"] %>">СорЕ1 тие зВорр1па</а> 


Корзина для покупок в действии была показана на рис. 5.9. 


* Отчет компании Зутатщес доступен по адресу Беер: / /Е1пуйт1 .сош/3а9 7и. 
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Атака 


Несложно заметить, что при такой реализации возникают условия для пассивной 
уязвимости Х55. Что произойдет, если злоумышленник убедит жертву посетить приве- 
денный ниже 91? 


ВЕСр:/ /вашСайт/Сат& /Тпдехзгекиги0т1="+оппопзетоуе="а1ете ('Х$5! ' } "+5ъу1е=" 
роз1Е1оп: а5 зо] фе; 1еЕё:0; кор: 0; и1аЕй:100%;Ье1а6е:100$; 


Обратите внимание, чго все это один длинный ОВГ. Если проанализировать, каким 
образом значение гебсогпОк1 внедряется в дескриптор <а>, то станет ясно, что у зло- 
умышленника имеется возможность добавлять произвольные атрибуты НТМГ. к деск- 
риптору <а>, причем эти атрибуты могут содержать сценарии. Приведенный выше ОБТ, 
просто демонстрирует уязвимость. выдавая назойливое всплывающее сообщение, как 
только пользователь переместит курсор мыпти где-нибудь на поверхности страницы. 

Подобным образом злоумышленник может запускать любые сценарии в контексте 
безопасности вашего домена, и вы становитесь уязвимыми для всех опасностей, пе- 
речисленных ранее. В частности, любой, кто заходит с административными правами, 
рискует, что его учетная запись будет взломана. Причем опасности подвергается не 
только одно конкретное приложение, а все приложения, размещенные в этом домене. 


На заметку! В этом примере код атаки передается как параметр строки запроса в УВЕ. Однако 
не думайте, что параметры формы (те. параметры РОЗТ) в зтом отношении более безопасны: 
злоумышленник может создать веб-страницу, которая содержит элемент <Еоги>, отправляю- 
щий код вашему сайту в виде запроса РОЗТ, и затем пригласить потенциальные жертвы посе- 
тить зту страницу. 


Защита 


Основная проблема связана с тем, что приложение выдает эхо-вывод произвольных 
введенных данных в виде неформатированной НТМЕ-разметки, которая может содер- 
жать в себе исполняемые сценарии. Ключевой принцип защиты от Х$$ можно сформу- 
лировать следующим образом: никогда не выводите переданные пользователем данные 
без предварительного их кодирования. 

Кодирование переданных пользователем данных означает трансляцию определен- 
ных символов в эквивалентные сущности НТМГ. (например, превращая <Ъ>"Сгеаё"</Ъ> 
в&1Е; Че; вапо®; Сгеа &<0о%; &1%; /Ъ Ее ;). Это гарантирует, что браузер будет трак- 
товать строку как литеральный текст, а не как код разметки, который может включать 
в себя сценарии. Подобная защита равно эффективна как против постоянных, так и 
против цассивных атак Х55. К тому же, кодирование осуществляется очень просто: по- 
надобится всего липть применить метод НЕи1.Епсоде (). 

Чтобы предотвратить описанную выше угрозу, визуализацию дескриптора ссылки 
следует изменить, как показано ниже: 


<а вкеЕЁ="<%= Нет1 .Епсо@е (У1емРафа["хебокиОк1"]} %>">СопЕ1тое зВорр1г9</ => 


Это блокирует атаку! Не следует забывать о применении вспомогательного мето- 
да НЕп1 .Епсоде () каждый раз, когда выводятся переданные пользователем данные. 
Единственный пропуск поставит под угрозу весь домен. 


5 Эта разновидность “социальной инженерии” не так уж трудна. Злоумышленник может 
настроить веб-сайт, который просто перенаправит посетителя по данному ОВГ.. носле 
чего постарается вызвать интерес к этому сайту у конкретного лица. отправив ему сооб- 
щение электронной почты (например, с фразой “Нашел интересные фото вашей жены. 
См. БЕЕр://...”), или заманить туда весь мир, организовав рассылку спама. 
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Конечно, предпочтительнее было бы, если бы синтаксис <%= ...%> предусматри- 
вал выполнение кодирования НТМГ, по умолчанию (за исключением вывода вспомога- 
тельного метода НТМТ) и позволял специальным образом помечать те редкие случаи, 
когда кодирование не требуется. К, сожалению, кодирование НТМ/, не является поведе- 
нием по умолчанию для механизма представлений \еБЕогил$, поэтому следует постоян- 
но помнить о необходимости каждый раз вручную писать <%= НЕт1.Епсоае(...) %>. 
Обратите внимание, что большинство встроенных вспомогательных методов НТМЕ 
(НЕТ. Асе1опттрК (), НЕт1.ТехеВох() и ти.} автоматически кодируют любые генери- 
руемые ими значения, что исключает необходимость делать это вручную. 


Средство проверки достоверности запросов АЗР.МЕТ 


Если вы работали ранее с АЗРМЕТ, то наверняка использовали другой способ бло- 
кировки атак Х5$, а именно — проверку достоверности запросов, которая появилась в 
версии АЗРМЕТ 1.1. 

Чтобы понять принцип этой проверки достоверности, следует учесть, что, начиная 
с версии АЗРМЕТ 1.0, некоторые элементы управления \еБЕогил$ выполняют автомати- 
ческое кодирование НТМГ. своего вывода, а некоторые — нет. Четкий критерий, опреде- 
ляющий то, какие серверные элементы кодируют свой вывод, а какие нет, отсутствует. и 
вряд ли подобная несогласованность задумывалась изначально. К, тому же, это причуд- 
ливое поведение невозможно изменить, не наруптив совместимости с унаследованны- 
ми страницами \’еБЕогтт5$. Тогда каким же образом команде разработчиков АЗРМЕТ 1.1 
удалось обеспечить последовательную защиту от атак Х5$? 

Решение состояло в полном игнорировании кодирования вывода, вместо которо- 
го предпринимались попытки отфильгровать опасные запросы в их источнике. Если 
опасные запросы не смогут достигнуть приложения АЗРМЕТ. то несогласованности 
кодирования вывода перестают быть проблемой, и разработчикам, игнорирующим во- 
просы безопасности, не понадобится учиться защищать свой вывод. В конечном итоге, 
разработчики из Мсгозой реализовали фильтр Х$$, который известен под названием 
проверки достоверности запросов, и включили его по умолчанию. Обнаружив подозри- 
тельный ввод, фильгр просто прекращает запрос и отображает сообщение об ошибке, 
как показано на рис. 13.2. 
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Рис. 13.2. Проверка достоверности запроса блокирует любой ввод, который содержит 
НТМЕ-дескрилтор 
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Достоинства и недостатки проверки достоверности запросов 


Проверка достоверности запросов хорошо выглядит в теории. Иногда она действи- 
тельно блокирует реальные атаки, защищая сайты. которые в противном случае были 
бы взломаны. Разумеется, это хоропо. 

Однако у медали есть и обратная сторона: проверка достоверности запросов создает 
У разработчиков ложное ощущение безопасности. За игнорирование разработчиками 
веб-приложений вопросов, связанных с защитой, впоследствии приходится расплачи- 
ваться, поскольку проверка достоверности запросов оказывается неадекватной по пере- 
численным ниже причинам. 


1. Проверка достоверности запросов препятствует законным пользователям вво- 
дить любые данные, которые хоть в малой степени похожи на НТМГ-дескриптор 
(наподобие текста “Я пишу код С# с использованием обобщений, например. 
1156<56:119>” и тд.). Такой совершенно безобидный запрос подавляется в за- 
родыше. Пользователь не получит сколько-нибудь внятного объяснения: его ста- 
рательный ввод будет просто отброшен. Это разочаровывает клиентов и вредит 
репутации разработчиков. 


2. Проверка достоверности запросов блокирует данные в точке их первоначального 
появления. Она не предоставляет никакой защиты от нефильтрованных данных, 
поступающих откуда-то еще (например, из другого приложения, которое совме- 
стно использует ту же самую базу данных, либо из предыдущей версии текущего 
приложения за счет импорта). 


3. Проверка достоверности запроса не обеспечивает никакой защиты, когда поль- 
зовательский ввод внедряется в НТМГ-атрибуты или блоки сценариев, как было 
показано в предыдущем примере с гебокпОт1. 


Довольно часто в реальных проектах приходится видеть, что разработчики полага- 
ются на проверку достоверности запросов, и выпускают свои приложения, не внедряя 
какой-либо другой вид защиты. Впоследствии менеджеры проектов получают жалобы 
от законных пользователей, которые не могут ввести некоторый текст с угловыми скоб- 
ками. Проверка показывает, что так оно в действительности и есть. Для исправления 
ошибки у программиста нет иного выбора, кроме как отключить проверку достоверно- 
сти запросов — на одной странице либо во всем приложении. Программист может не 
осознавать, что его устойчивое к атакам Х$$ приложение теперь стало уязвимым для 
них, или, что более вероятно, он осознает это, но уже переключился на другой проект 
и не может вернуться к предыдущему. В результате весь смысл безопасности сводит- 
ся на нет, что в долговременной перспективе приводит к еще болышпей уязвимости веб- 
приложения. 

В АЗРМЕТ МУС проверка достоверности запросов по умолчанию включена. Чтобы 
отключить ее для определенного метода или во всем определенном контроллере, можно 
воспользоваться фильтром [Уа11дафеТпри+], как показано ниже: 


[Уа11ЧафеТпрое (Еа15е)] 
ручЮ11с с1аз$ МуСопего11ехт : Сопеко11ег { ... } 


Обратите внимание. что в АЗРМЕТ МУС отсутствует возможность глобального от- 
ключения проверки достоверности запросов в файле меь .сопЕ1 сд, как это можно делать 
в \еБЕогтл$ установкой параметра <радез уа11Чатевеслезе="Еа1зе">. Эта установка 
игнорируется. Тем не менее, глобально отключить эту проверку можно в фабрике эле- 
ментов управления, присваивая значение Га1зе свойству Уа11Чафхевесцез+ на каждом 
контроллере при его создании. 
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Оценка соотношения преимуществ проверки достоверности запросов и связанных 
с ней опасностей возлагается на разработчика. Однако не следует выбирать проверку 
достоверности запросов как единственное средство защиты. Но причинам, описанным 
ранее, кодирование НТМГ. любого пользовательского ввода по-прежнему остается акту- 
альным. Если кодирование НТМТ, пользовательского ввода реализовано повсеместно, то 
проверка достоверности запросов защиту не усилит. но неудобства в работе законных 
пользователей создаст. 


Фильтрация НТМЕ с использованием 
пакета НТМЕ Адйну Раск 


Иногда реализовать кодирование НТМГ, для всего пользовательского ввода попросту 
невозможно: переданные данные должны отображаться с использованием избранного 
перечня безопасных НТМГ-дескринторов. В общем случае это очень трудная работа, по- 
скольку существуют сотни неожиданных путей сокрытия опасной разметки в хоропю или 
плохо оформленной НТМГ-разметке (по адресу НЕср: //ва.скегз .ота/хз$ .НЕщт приве- 
ден замечательный список примеров). Для этого недостаточно просто удалить дескрипто- 
ры <зст1рЕ>! Каким же образом отличать безопасную и небезопасную НТМГ-разметку? 

На СодеРех (уму . содер1ех.сопв/) существует великолепный проект под названи- 
ем НТМЕГ Адййу Раск. Это библиотека классов „МЕТ, с помощью которой можно прово- 
дить разбор НТМГ-разметки и довольно точно оценивать, как интерпретировать плохо 
оформленную НТМГ-разметку в ООМ-подобную древовидную структуру. Инструкции по 
загрузке и установке доступны по адресу ими. содер1ех . сом/Н1ач111$урасК/. 

В приведенном ниже коде служебного класса Нки1Е11]6ех показано, как исполь- 
зовать объект Н&м]1Росимеп® из пакета НТМТ, Абу РасК для удаления любых НТМТ- 
дескрипторов, кроме перечисленных в списке разрешенных. Этот класс можно раз- 
местить в любом месте приложения и затем ссылаться на него из представлений 
МУС. Чтобы приложение скомпилировалось, понадобится добавить ссылку на проект 
Нет А91 11$ уРасК или на скомпилированную сборку. 

Обратите внимание, что единственным возможным выводом (который формируется 
тремя выделенными строками) будет либо НТМГ-кодированный дескриптор, либо деск- 
риптор из списка разрещенных. 

8119 Неи1Ач111суРаск; 

раБ11с зфаЕ1с сТазз НЕи1Е11Еек 

{ 

руБ11с збаЕ1с зЕх1па Е11фехк(зЕт1па НемЪ, з6г109[] а11омедТааз) 
{ 
НЕи1Росомепе дос = пем Нем1Росищмепе (); 
ос .ТоаЯНе1 (61); 
ЗЕг1па9Ви11ает БаЁЕЕег = пеи 5&х1раВи119ек(); 
Ргосез5$ (Чос.РосишепЕМоае, БаЕЕег, а11омеЯТадз); 
тебога БоЕЕехг.Тозетлпа (); 
} 
зта®1с зЕх1п9[] ВемоуеСв119гепОЕТадз = пем з6т1п9[] { "зскаре", "зеуте" }; 
зСаф1с уо1а Ргосез$ (Ни Моде поде, 5$Ег109В0119ег роЕЕег, з&г1п9[] а11оиедТааз) 
{ 
зи1Есв (поде.МодеТуре) 
{ 
сазе Неп1МоаеТуре.Техе: 
БоЕЕег .Аррепа (НЕЕро&111 у .НЕп1Епсоде ( ( (НЕп1ТехеМоде) пойе) .Тех®)); 
ргеак; 
сазе Нем1МоаеТуре.Е1ещепт: 
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сазе НЕм1МоаеТуре .Росищепе : 

роо1 а11оме@Тад = а11омеЯТадз .Сопеа1п$ (по@е .Маще.ТоГоиег ()); 
1Е (а11омеЯТаа) 

БаЕЕехг .АррепаГогта* ("<{0}>", поае.Мапе); 
1Е (!ВепоуеСр119гепоЁЕТадз .Сопка1пз (поде .Маме) } 

ЕогеасВ (Неп1Моде св119Моде 1п поде.Сь119Модез) 

Ргосезз (с1119Мо4е, БаЕЁет, а11омеЯТадз); 

1Е (а11омеЯТаа) 

БоЕЕег.Арреп@Еогта® ("</{0}>", поае.Мате) ; 
ЬгеаКк; 


} 
Теперь попробуйте поместить в шаблон представления следующую разметку: 
<$=Нем1Е11ех.Е11 ег ("<©>Не11о</Ъ> <и><1>иотг19</1></а> 


<зсу1рЕ>а1ег ('Х');</зск1рЕ>", 
пем 56 г1та[] { "Ъ", "1", "Оу", "зрар" }) //разрешить только эти дескрипторы %> 


В результате получается хорошо оформленный, отфильтрованный вывод НТМГ: 
<Ь>Не11о</Ъ> <1>мог19</1> 


Как видите, этот фильтр безусловно отбросил все атрибуты дескриптора. Если не- 
которые атрибуты должны быть разрешены (например, <1иа зкс="иг1">), следует 
добавить строгую проверку достоверности для этих атрибутов, поскольку существует 
множество способов внедрения сценариев в обработчики событий, подобные оп1оаа 
и оптоцзеотек, и даже в атрибуты згс и зе у1е. (см. мии .по2111а.ока/зесик1®у/ 
аппоипсе/2006/иЕза2006-72.вВЕм1). 

Это не значит, что пакет НТМГ, АбПцу РасК идеален и лишен недостатков, но во мно- 
гих случаях он демонстрирует свою эффективность. 


Внимание! Ранее уже отмечалось, но не лишним будет повторить: не стоит изобретать собствен- 
ный фильтр НТМЕ с нуля! Хотя решение этой задачи вызывает интерес у многих разработчи- 
ков, на самом деле чрезвычайно трудно предусмотреть все возможные разновидности плохо 
оформленной НТМЕ-разметки, приводящие к выполнению сценариев (вроде перечисленных по 
адресу ПЕЕр: //ва.скегз.ога/хзз .Вт1.). Любой, кто надеется справиться с этим посред- 
ством регулярных выражений, ошибается. Именно потому представленный ранее код основан 
на использовании проверенного анализатора НТМЕ Аду Раск. 


Перехват сеанса 


Вы уже видели, что атаки Х$$ могут позволить злоумышленнику запустить произ- 
вольный сценарий в контексте вашего домена. После этого может быть предпринята 
попытка захватить контроль над регистрационной записью жертвы. Чаще всего приме- 
няется стратегия перехвата сеанса (также называемая похищением сооКе-наборов). 

Во время сеанса браузера АЗРМЕТ идентифицирует посетителя по соо е-набору с 
идентификатором сеанса (по умолчанию он называется АЗР.МЕТ 5е5з1овт4]), а если 
используется аутентификация Еогил$ АиепйсаНоп — то по сооКе-набору аутентифи- 
кации (по умолчанию он называется .АЗРХАОТН). Первый соое-набор просто содер- 
жит СОШ-подобную строку, а второй — заптифрованный пакет данных, указывающий 
идентичность аутентифицированного пользователя. Если злоумышленник сумеет полу- 
чить значения из любого или из обоих сооКе-наборов, то сможет поместить их в собст- 
венный браузер и затем восприниматься вашим сервером как законный пользователь. 
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При этом с точки зрения сервера злоумышленник и его жертва становятся неразличи- 
мыми. Обратите внимание, что злоумышленнику даже не понадобится расшифровы- 
вать .АЗРХАОТН. 

Изначально предполагается, что никто со стороны не может прочитать соое-набо- 
ры, ассоциированные с вашим доменом, потому что они не отправляются ни в какой 
домен третьей стороны, а современные браузеры достаточно хорошо предотвращают 
чтение и передачу средствами УЗауаЗ сре информации через границы домена. Но если 
злоумышленник сможет выполнить Чауа$сире-код в контексте вашего домена, то ему не 
составит болышого труда прочитать эти соое-наборы и получить нужные сведения: 


<зсЕ1рЕ> 

уаг 19 = Чосощеп®е. сгеаееЕ1етей® ("1МС"); 

109.зтс = "БЕЕр://аебаскег/теселуерака?соок1ез=" + епсодейвТ (досимеп®е .сооК1е}; 
Чосипепе .роду .аррепЯСВ119 (19); 

</зст1рЕ> 


Как бы тщательно не ликвидировались уязвимости к атакам Х$$, никогда нельзя 
гарантировать их полное отсутствие. Вот почему всегда имеет смысл устанавливать до- 
полнительный уровень защиты от перехвата сеансов. 


Защита с помощью проверки |Р-адреса клиента 


Если фиксировать {Р-адрес каждого клиента при запуске сеанса, то можно будет от- 
клонять любые запросы, поступающие от чужого {Р-адреса. Это значительно уменышает 
угрозу перехвата сеансов. 

Недостаток этого приема связан с тем, что иногда существуют совершенно законные 
основания для изменения ГР-адреса клиента во время существования сеанса. Например, 
после неожиданного разрыва соединения с поставщиком Интернет-услуг и последую- 
щей установки нового соединения клиенту может быть назначен другой ГР-адрес. Или 
поставщик Интернет-услуг может пронускать НТТР-трафик через набор прокси-серве- 
ров. балансирующих нагрузку. так что каждый запрос в сеансе может поступать с ка- 
кого-то другого ГР-адреса. 

Требовать неизменность {Р-адреса клиента имеет смысл только в корпоративных се- 
тях, когда известно, что сеть может обеспечить такое постоянство. В общедоступных 
сетях наподобие Интернета такого подхода следует избегать. 


Защита с помощью установки флага 
НЕЕрОпТу для сооКе-наборов 


В 2002 г в МсгозоЁ рептили добавить в Н\егоеё Ехр]огег важное средство обеспече- 
ния безопасности: соое-наборы НЕЕрОпТу. С тех пор это средство стало стандартом 
де-факто и поддерживается в браузере ЕпеЮх, начиная с версии 2.0.0.5 (июль 2007 г). 

Положенная в основу идея проста: соое-набор помечается флагом НЕЕрОпТу, и 
браузер скрывает его существование от дЗауа5сир-кода, но продолжает передавать 
в НТГР-запросах. Это предотвращает упомянутый ранее взлом ХЗ$5 методом чтения 
соое-наборов в контексте ватиего домена и то же время позволяет применять соое- 
наборы для отслеживания сеансов и аутентификации веб-сервером. 

Возьмите на вооружение простое правило: помечайте все уязвимые соо е-наборы 
флагом НЕЕрОп1у, если только нет какой-то специфической и редкой причины обра- 
щаться к ним из клиентского ЗауасИре-кода. В АЗРМЕТ по умолчанию помечаются 
флагом НЕЕрРОПТу сооНе-наборы АЗР.МЕТ безз1огтТ и .АЗРХАОТН. Пометка этим фла- 
гом других соо е-наборов осуществляется следующим образом: 
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Везропзе.Соок1ез .Ада (пем НЕЕрСооКте ("МуСоок1е") 
{ 


Уа1ае = "му уа1ае“", 
НЕЕРОПТу = Ехое 
$); 


Этот способ не обеспечивает абсолютную защиту от похищения соок1е-набора, так 
как содержимое последнего может быть где-то непреднамеренно раскрыто. Например, 
при наличии страницы обработки ошибок, которая для целей отладки отображает вхо- 
дящие НТТР-заголовки, межсайтовый сценарий может легко вызвать ошибку и прочи- 
тать значения соое-набора со страницы ответа. 


Межсайтовая подделка запросов 


Всецело сосредоточиваясь на атаках Х$$, многие веб-разработчики не обращают 
внимания на равно деструктивную и даже более простую форму атаки межсайтовой 
подделкой запросов (СЪВЕ). Это настолько простая и очевидная методика проведения 
атак, что ею часто пренебрегают 

Рассмотрим веб-сайт, который позволяет зарегистрированным пользователям входить 
и управлять своим профилем через контроллер по имени ОзегРтоЕ11еСопеко11ех: 


руЮ11с с1аз$ ОзегРкоЕ11еСопетго11ег : Сопго11ех 


{ 
руЮ11с У1емВезо1е Еа1()} 


{ 
// опущено: заполнение У1ем Баба цеталями профиля, 
// чтобы он мог быть визуализирован представлением 
тееаги Улем(); 


} 


рир11с УземВези1Е Забил ЕОрдаее (} 

{ 
// Получение существующих данных пользовательского профиля (реализация опущена} 
РгоЕ11ераба ргоЕЁ11е = сееТодаедТп0етРтгоЕ11е(}; 


// обновление объекта пользователя 

ргоЕ11е.Ета11Адатезз = Ведаезе.Еоги["ета11"]; 

ргоЕ11е.Гауот1ееНобру = Весчезе .Еотщ["ВоББу"]; 

Зауе0зегРтоЕ11е (ргоЕ11е}; 

Тепррафа["шеззаде"] = "Уоцг ргоЁ11е маз ирЧдафея."; // Профиль обновлен 
теЕатги У1ем(); 


} 


Сначала посетители обращаются к методу действия ЕЧ1 (), отображающему теку- 
щие детали профиля на форме <Еоги>, которая, в свою очередь, отправляет их обратно 
в Зари: ЕОрдаее (). Метод действия бибт1 Е Орааее (} получает отправленные данные и 
сохраняет их в базе данных сайта. Уязвимости Х$5 исключены. 


Атака 


На первый взгляд, код выглядит вполне безобидно, поскольку является типичным 
при решении задач подобного рода. Однако. к сожалению, любой злоумышленник мо- 
жет предпринять опустоптительную атаку, сумев убедить одного из пользователей сайта 
посетить следующую НТМГ-страницу, расположенную в некотором внешнем домене: 
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<БоЯу оп1оад="аоситепЕ . деЕЕ1ещерпеВутАа ('ЁЕп1') . зоба () "> 
<Еоги 19="Н11" асбтоп="ВЕЕр : //уостз1Ее/ОзегРтоЕ11е/5ири1ЕОрЯаЕе" терод="розЕ"> 
<1приЕ памше=“ета11" уа]1ое="раскег@зотеитеге.еу11" /> 
<1праЕ папе="БоБру" уа1ще="РеЕаслаа мебзлафез" /> 
</Еоти> 
</Боду> 


После загрузки эта вредоносная страница просто передает отправленную форму на 
обработку методу действия 5ибм1 Е Ордасе (). Если исходить из того, что на сайте реа- 
лизована некоторая система аутентификации на основе соо е-наборов, и у посетителя 
имеется в данный момент действующий соое-набор аутентификации, браузер отпра- 
вит его в запросе, а сервер предпримет действие в ответ на запрос, как если бы этот 
запрос запускался жертвой. Аналогично уязвима и аутентификация УЙпаомз. Теперь в 
качестве адреса электронной почты в профиле жертвы установлен тот что находится 
под контролем злоумышленника. Затем злоумышленник может воспользоваться сред- 
ством восстановления забытого пароля и получить доступ к регистрационной записи 
со всей ее конфиденциальной информацией или административными привилегиями, 
которыми она обладает 

Вредоносная страница может легко скрыть свои действия, например, молча отпра- 
вив запрос РОТ с помощью Адах (через ХМГНЕЕрВеацез*). 

Если этот пример не кажется вам убедительным, то подумайте о других действиях, 
которые может выполнить приложение, выдав единственный НТТР-запрос. Возможно, 
это будет покупка товара, удаление какого-то элемента, проведение финансовой тран- 
закции, публикация статьи, увольнение кого-либо из персонала, а то и вовсе запуск 
ракеты. 


Защита 


Существуют две основные стратегии защиты от атак СВЕ, 


® Проверка достоверности входящего НЛТР-заголовка ВеЕетгег. При выполнении 
любого НТТР-запроса большинство веб-браузеров настроены так, чтобы переда- 
вать исходный ОВ! в НТТР-заголовке под названием ВеЕегех (в АЗРМЕТ он пред- 
ставлен свойством Ведиез®.0х1ВеЕеггег (причем здесь слово “гееггег” написано 
правильно)). Если в результате его проверки обнаруживается. что он ссылается на 
неожиданный чужой домен, это означает, что поступил межсайтовый запрос. 


Однако браузеры не обязаны посылать этот заголовок, и некоторые пользовате- 
ли отключают его отправку, чтобы защитить конфиденциальность. Кроме того, 
иногда злоумышленникам удается подделать заголовок ВеЁЕегег в зависимости 
от версии установленного у потенциальной жертвы браузера и программы РазВ. 
Таким образом, проверка достоверности входящего НТТР-заголовка ВеЁегехг яв- 
ляется слабым решением. 


® Включение в уязвимые запросы специфичного для пользователя маркера. Если 
вы требуете от своих пользователей ввода пароля в каждой форме. то никто посто- 
ронний не сможет подделать межсайтовые отправки (поскольку ему не известен 
пароль регистрационной записи пользователя). Однако это приведет к возникно- 
вению серьезных неудобств в работе законных пользователей. Лучий вариант 
состоит в том, чтобы заставить сервер генерировать секретный маркер, специ- 
фичный для пользователя, поместить его в скрытое поле формы и затем прове- 
рять его наличие и корректность при отправке формы. В АЗРМЕТ МУС имеется 
тотовая реализация этой стратегии. 
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Предупреждение атак С$ВЕ с помощью 
противоподделочных вспомогательных методов 


Обнаруживать и блокировать атаки СЗВЕ можно за счет комбинирования вспо- 
могательного метода НЕп1.АпЕ1ЕогдегуТоКкев () из АЗРМЕТ МУС и его фильтра 
[Уа11ааъеАлЕ1ЕогдегуТокею]. Чтобы защитить определенную НТМГ-форму, включите 
в нее вызов метода НЕ] .АпЕ1РогдегуТокеп (), например: 


<$ из1па (Нёт1 .ВедаоРоги()} { %> 
<%= НЕп1 .АпёаАЕогдегуТокеп () %> 
<!-- остальная часть формы --> 
<$ } %> 


Резульгирующая разметка выглядит следующим образом: 


<Еоги асЕ1оп=" /ОзегРгоЕ11е/Зиби1ЕОрЧаЕе" шеЕВБод="розе" > 


<1прие паме="_ Ведлезе\Уег1Е1салопТокеп" Еуре="Ь194еп" уа1ще="клйорОтейЬХ..." /> 
<!-- гезе оЁ Еога доез Цеге --> 
</Еоги> 


В то же время вспомогательный метод Нёп1 .АрЕ1ЕогдегуТоКер () предоставит по- 
сетителю соое-набор, имя которого начинается с __Весиез&\Уег1Е1са1отТокКев. Этот 
соо е-набор будет содержать то же самое случайное значение, что и соответствующее 
скрытое поле. Это значение остается постоянным на протяжении всего сеанса браузера 
посетителя. 

Затем необходимо проверить достоверность отправок форм, добавив для этого атри- 
бут [Уа11дафеАп®1ЕогдекутТокеп] к целевому методу действия. Например: 


[Ассер&УегЬз (НЕЕрУегЬ5.Роз®)] [Уа11ЧафеАпЕ1ЕогаегуТокеп] 
руБ11с УлемВезо1е Забил Ордаее {() 
{ 


// Остальной код без изменений 


} 


[Уа119афеАпЕ1РГогдегуТоКевп] — это фильтр авторизации, который проверяет наличие 
во входящем запросе элемента Весдаез® .Еоги по имени _ Ведаез(\Уетг1Е1са 1опТокеп, 
факт поступления запроса с соое-набором, имеющим соответствующее имя, а также 
совпадение их значений. Если одна из перечисленных проверок не проходит, генери- 
руется исключение с сообщением "А гедийгей ап-Югвегу 1оКеп \”аз поф заррНеа ог \маз 
1луаПа” (Обязательный противоподделочный маркер отсутствует или неверен) и запрос 
блокируется. 

Такая реализация препятствует атакам СЪКЕ, поскольку даже если потенциальная 
жертва имеет активный сооЖе-набор _ ВедаезЕУег1 Е1са1опТоКеп, злоумышленник 
не будет знать его случайное значение, а потому не сможет применить правильный 
маркер в скрытом поле формы. Законные пользователи не почувствуют неудобств, так 
как механизм полностью прозрачен. 


Совет. Если различные НТМЕ-формы в веб-приложении должны защищаться независимо друг 
от друга, необходимо задать начальное значение ($а!) в скрытом поле формы (например, 
<$= НЕ .АпЕ1ЕогдегуТокеп ("изегРхоЕ11е") %>) и соответствующее значение в 
фильтре авторизации (например, [Уа11ЧасеАпе1ЕогаегуТокеп (5а1="иозехРхгоЕ11е"} |). 
Эти начальные значения имеют вид произвольных строк. Разные начальные значения означают 
генерацию различных маркеров, поэтому даже если злоумышленник каким-то образом заполу- 
чит противоподделочный маркер приложения, то не сможет повторно использовать ее где-либо 
еще, где требуется другое начальное значение. 
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Обратите внимание, что имя противоподделочного соое-набора на самом деле со- 
держит суффикс, который варьируется в соответствии с именем виртуального каталога 
приложения. Это предотвращает нежелательное взаимное влияние друг на друга несвя- 
занных приложений. Кроме того, вспомогательный метод Нет]. .АпЕ1ЕогдекуТокег () 
принимает необязательные параметры расН и Ядота1п, которые являются стандартны- 
ми для соое-наборов. Они управляют тем, каким ОВ! разрешено видеть соок‘е-наборы. 
Например, если значение ра В не установлено, то противоподделочный соое-набор 
будет виден всем приложениям, размещенным в домене (это поведение по умолчанию, 
которое подходит для большинства приложений). 

Такой подход к блокированию атак СЗВЕ работает хорошо, но имеет некоторые 
ограничения. 


® Браузеры законных посетителей должны принимать сооче-наборы. В противном 
случае фильтр [Уа11ЧасеАре1ЕогаекуТокеп] всегда будет отклонять отправку 
форм из них. 


® Этот подход работает только с формами, присылающими запросы РОЗТ, а не СЕТ 
Данная проблема не возникнет, если вы следуете рекомендациям по работе с про- 
токолом НТТЕ, которые гласят, что запросы СЕТ должны предназначаться только 
для чтения (те. не должны что-либо изменять, например, записи в базе данных). 
Эти рекомендации подробно рассматриваются в главе 8. 


® Данный подход легко обойти, если где-нибудь в домене присутствуют уязвимости 
Х$5. Любая брешь подобного рода позволит злоумышленнику проверить текущее 
значение _ КедоезеУет1Е1са&1опТоКеп жертвы и затем использовать его для 
подделки корректной отправки. Словом, берегитесь уязвимостей к атакам Х$%! 


Внедрение кода $01. 


Если бы проблемы безопасности выдвигались на премию Оскар, то внедрение кода 
ЗОГ (5ОГ ИицесНоп) ежегодно завоевывало бы приз “За наиболее распространенную и 
опасную проблему безопасности в веб-приложениях” с 1998 г до примерно 2004 г Эта 
угроза остается наиболее знаменитой, наверное. потому, что ее легче всего понять, хотя 
в наши дни она менее распространена, чем уязвимости клиентской стороны. 

Возможно, вы знаете, что собой представляет внедрение кода ЭОГ. Если же нет, то 
взгляните на следующий пример уязвимого метода действия АЗРМЕТ МУС: 


руб11с АсЕфопВези1Е ГодТл (5Ег1п9 изегпаме, 5Ег1па раззиога} 
{ 
5Ег14п9 591 = зЕг1па .РГогта® ( 
"ЗЕЪЕСТ 1 ЕВОМ [О5ег5] ИНЕВЕ Озегпапе=' {0}' АМР Раззиог4=' {1}' м 
и5егпаше, раз5мога); 
/ Предполагается наличие служебного класса для такого выполнения запросов 80 
Рафатаь1е гезо15 = МурафаЪазе .ЕхесифеСоптап@ (пеи 591Соштала (541)); 
1Е (гезо165.Вом$.Сонпе > 0) 
{ 
// Войти в систему с извлеченным из базы данных именем пользователя 
ЕогизАиеВепе1саЕ1оп.берАйцЕНСоок1е (изегпате, Еа15е); 
тебсаги ВедтгесЕТодАсСЕ1оп ("Тпаех", "Ноце"); 


} 


е1зе 


{ 
Тепррафа["меззаде"] = "Зоггу, 10940 Еа11еЯ. Р1еазе Еку ада1п"; 
// Сбой процедуры входа 
тебого Вед1гесЕТодсЕТоп ("Тод1оРкомре"); 
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Атака 


Проблемным кодом является тот, который динамически конструирует и выполняет 
ЗОГ-запрос (он выделен полужирным). В этом коде не предпринимается попытка про- 
верить или закодировать переданные пользователем значения озегпаме или раззиога, 
поэтому злоумышленник может легко войти от имени любого пользователя и указать 
пароль Б1аб' ОБ 1=1 --, потому что в результате получится запрос следующего вида: 


ЗЕТЕСТ 1 ЕВОМ [95ет$] ИНЕВЕ Озегпаце=' апуопе' АМО РаззмогЯ='Б1ай' ОВ 1=1 --' 


Етце хуже, если злоумышленник укажет изегпаще или раззиота, содержащие 
'; ОВОР ТАВГЕ [Фзег$] -- или, что совсем плохо, '; ЕХЕС хр ст@зВе11 'Еохтаф с:' --. 
Ограничить потенциальный ущерб могут тщательно продуманные ограничения регист- 
рационной записи ЗСТ, Зегуег, но сама по себе ситуация скверная. 


Защита кодированием вводимых данных 


Разработчики с опытом программирования на РНР часто применяют подход на ос- 
нове проверки достоверности или кодирования входных данных перед встраиванием их 
в динамический запрос ЗОТХ, например: 

ЗЕт1п9 591 = зе т1фпа. ЕГогта® ( 

"ЗЕГЕСТ 1 ЕВОМ [Озегз] ИНЕВЕ Озегпаце=' {0}' АМО Раззмога=' {1}'", 
изетпаме. Вер1асе("'", "''"), раззмога.Бер1асе("'", "'!'")); 


Если вы работаете с ЗОГ, Зегуег, то не используйте таких решений. Защита тако- 
го рода не только неудобна, поскольку нужно постоянно помнить о необходимости ее 
реализации, но и ненадежна, так как существуют способы ее обхода. Например, если 
злоумышленник заменит ' на \', то получится \'', но \' — специальная управляю- 
щая последовательность, так что атака возобновится, причем приобретет персональ- 
ный характер. 


Защита с использованием параметризованных запросов 


Более надежное решение предусматривает использование параметризованных за- 
просов ЗОБ Зегуег вместо простых динамических запросов. Одна из форм параметри- 
зованных запросов являются хранимые процедуры, но с не меньшим успехом можно 
отправить параметризованный запрос непосредственно из кода С*#”, например: 


зЕу1па чаегу = "ЗЕТЕСТ 1 ЕВОМ [05егз] ИНЕВЕ Озегпапе=@изегпате АМО Раззмогд=@риа"; 
За1Сошмапа сошмапЯ = пем 5а1Соитапа@ (аиеку} ; 

сопмапЯ .Рагащефет$.Ада ("@изегпате", 59106Туре.МУатСрах, 50) .Уа1иае = изегпаие; 
соптапа.Рагацекегз.Ада ("@риа", 5а106Туре .МУагСваг, 50) .Уа1е = раззиога; 
РасаТар1е гези1Е$ = Мурабаазе .ЕхесоеСоптапа (сошмаюа} ; 


В приведенном примере значения параметров вынесены за пределы исполняемой 
структуры запроса. Это исключает возможность, что хитро сконструированное значе- 
ние параметра может быть интерпретировано как исполняемый ЗОГ-код. 


6 вовсе не ради критики РНР или его приверженцев: имейте в виду, что многие приложения РНР 
используют в качестве базы данных МуЗОГ, а в МуЗОГ. до конца 2004 г. отсутствовала концеп- 
ция подготовленных операторов (эквивалент параметризованных запросов в ЗСТ, Зегует). 


7 Многие утверждают, что хранимые процедуры быстрее и безопаснее, но это не всегда соот- 
ветствует действительности. Хранимые процедуры — это не что иное, как параметризован- 
ные запросы, только хранящиеся в базе данных. Кэширование плана выполнения выпол- 
няется одинаково. Речь не о том, чтобы не пользоваться хранимыми процедурами, а о том, 
что делать это не обязательно. 
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Защита с помощью объектно-реляционного отображения 


Угроза внедрения кода ОГ, абсолютно разрушительна, но не является распростра- 
ненной в современных приложений. Одна из причин состоит в том, что большинство 
веб-разработчиков теперь осведомлены об угрозе, а другая — в том, что современные 
платформы программирования часто включают в себя встроенную защиту. 

Если код доступа к данным построен на основе любого инструмента объектно-ре- 
ляционного отображения (оШес{-гаНопа!] тшарр1ая — ОВБМ), такого как ГЛМО ю $О1, 
МНегпа{е или Мсгозой ЕпЫфу Егатеч\огК, то все отправляемые запросы являются па- 
раметризованными. Если только не предпринимаются какие-то необычно опасные дей- 
ствия, например, динамическое конструирование непараметризованных запросов НОЁ 
или Епёну ОГВ с конкатенацией строк, то угроза внедрения кода ЗОГ, устраняется. 


Безопасное использование МУ\УС Егатемогк 


Итак, мы рассмотрели общие проблемы безопасности приложений. разновидности 
атак и способы защиты в контексте АЗРМЕТ МУС. Это хорошая отправная точка, но для 
защиты приложений МУС понадобится также ознакомиться с некоторыми опасностя- 
ми, связанными с неправильным применением самой платформы МУС ЕгатечогК. 


Неумышленное раскрытие методов действий 


Любой общедоступный метод класса контроллера по умолчанию является методом дей- 
ствия и, в зависимости от конфигурации маршрутизации, может быть вызван кем угодно 
из Интернета. Это далеко не всегда то, что программист имел в виду. Например, в следую- 
щем контроллере предполагается, что доступным должен быть только метод Стапде (): 


руБ11с с1аз5 РаззиогЯСопетко11ет ; Сопего11ех 

{ 
ри511с АсЕ1опВези1е Свапде(з6т1п9 о1арма, зет1па пемриа, зЕт1па пеириЯСопЕттут) 
{ 


зЕг1пд изегпаше = НЕбрСопеехе .Озег. ТаепЕ1Еу.Мапе; 


// Проверить правомерность запроса 
ТЕ ((пемриа == пемри@СопЕ1тщ) && Му0зегз.\Уег1ЕуРаззмога (изеграте, о1армод) ) 
РоРаззмогЧСВапае (изегпате, пемриа); 


// ... теперь перенаправить или визуализировать представление ... 


} 


риЮ11с уо1а РоРаззиогЧСвапае (3&г1п9 изегпаме, зет1п9 пемраззиога) 
{ 

// Запрос уже проверен выше 

Озег чзегк = Му0Озегз .сеЕОзег (изегпапе) ; 

изег. бе-Раззиога (пемраззиога)} ; 

Му0зег$ .зауе0зет (и5ег); 


8 НОГ, и Ей ЗОТ, — это основанные на строках языки запросов, поддерживаемые МНЪеграе 
и Ей у Егатлемо[К соответственно. Оба выглядят и работают подобно ЗСТ, но оперируют кон- 
цептуальным представлением модели предметной области, а не лежащими в основе таблицами 
базы данных. Обрагите внимание, что МНЪФегпае также может опрашиваться через встроен- 
ный АРГ-интерфейс [СгНепа, а Е ош ЕгаплеуогК поддерживает запросы 1Л\О, так что обычно 
не придется обращаться к конструированию запросов НОГ. или Е пу ЭСТ. на основе строк. 
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В этом коде метод РоРаззиогаСтапае () по рассеянности (или со злым умыслом) по- 
мечен как роб11с (это слово набирается настолько часто, что пальцы могут иногда опе- 
режать мысли), что создает едва заметную лазейку. Метод БоРаззмогаСвапае () может 
быть вызван непосредственно для изменения чужого пароля. 

Обычно нет причин делать методы контроллеров общедоступными, если они не 
должны быть методами действий, потому что повторно используемый код чаще отно- 
сится к модели предметной области или служебным классам, а не к классам контрол- 
леров. Однако если все-таки в контроллере нужен общедоступный метод, который не 
будет методом действия, не забудьте снабдить его атрибутом [МопАсЕтоп]: 


[МопАсе1оп] 
руб11с уо1а РоРаззмог@СВароае (36х1п9 изегпатме, з&х1п9 пемраззмога) 


{ 


/* остальной код не изменяется */ 


} 


Благодаря наличию атрибута [МопАсе1оп], МУС ЕгатемотК не позволит выполнять 
сопоставление этого метода с любым входящим запросом, а также обрабатывать запрос. 
В то же время этот метод можно будет вызывать из другого кода. 


Предотвращение изменения уязвимых 
свойств привязкой модели 


Об этом уже упоминалось в главе 11, но стоит повторить и здесь. Когда привязка 
модели заполняет объект. полученный в качестве параметра метода, или ке объект, об- 
новление которого явно запрашивается через привязку модели, она при этом по умол- 
чанию выполняет запись в каждое свойство объекта, для которого во входящем запросе 
указано значение. 

Например, если метод действия получает объект типа Воок1п9, где Воок1пча имеет 
свойство 1пе по имени 01зсоппеРегсеп®, то злоумышленник может добавить к ОВГ 
фрагмент ?01зсоопЕРегсепе=100 и отпраздновать выходные за ваш счет (а кто бы 
отказался от скидки 100%2). Чтобы предотвратить это, с помощью атрибута [В1п9] 
можно установить список. ограничивающий свойства, которые разрешено заполнять 
привязке модели: 


ри511с АсЕтопВезиа1е 
ЕО ( [В1п9 (Тос1таае = "МипАЯо1ез, МипСЬ119тет"}] Воок1па Роок1т9) 


Пек И ТЕДи ча 
} 


В качестве альтернативы атрибут [В119] можно применять для установки списка 
свойств, которые привязке модели модифицировать запрещено. За более подробной ин- 
формацией обращайтесь в главу 11. 


Резюме 


В этой главе было показано, что НТТР-запросы легко поддаются манипуляции и под- 
делке, и потому необходимо заботиться о защите разрабатываемого веб-приложения, 
не полагаясь на то, что происходит за пределами веб-сервера. Вы узнали о наиболее 
распространенных векторах атак, используемых в наши дни, включая междоменные 
атаки, а также о том, как защищать от них приложение. 

В следующей главе речь пойдет об установке приложений на работающем публич- 
ном веб-сервере. Процесс развертывания приложений АЗРМЕТ МУС будет рассмотрен 
на примерах веб-серверов ПУ 6 и П$ 7. 


ГЛАВА 14 


Развертывание 


Р азвертывание — это процесс установки веб-приложения на действующий публич- 
ный веб-сервер для предоставления доступа к нему реальных пользователей. Если 
ранее уже приходилось развертывать приложения АЗРМЕТ, то будет приятно узнать, 
что развертывание АЗРМЕТ МУС сводится к практически тем же самым действиям. 
Единственная новая сложность связана с маршрутизацией (при попытке использова- 
ния ОКТ. без расширений на сервере П$ 6}, но даже она легко преодолима, если знать, 
как это делать. 
В этой главе рассматриваются следующие вопросы. 


® Требования к серверу для размещения на нем приложений АЗРМЕТ МУС. 
° Архитектура обработки запросов П$, и место маршрутизации в ней. 


® Установка веб-серверов П$ 6 и П$ 7 в среде ОС УЯпао\з Зегуег и развертывание 
на них приложений АЗРМЕТ МУС. 


° Проектирование приложений с учетом конфигурируемости для обеспечения их 
эффективного функционирования в среде разработки и производственной среде. 


Требования к серверу 


Для запуска приложений АЗРМЕТ МУС сервер должен отвечать перечисленным 
ниже требованиям. 


® Иметь установленный веб-сервер П$ 5.1 или последующей версии с включенной 
поддержкой АЗРМЕТ 


® Иметь установленную платформу „МЕТ Егате\могк версии 3.5 (предпочтительно с 
пакетом обновлений $Р]). 


Кроме того, на сервере должна быть установлена операционная система Улпаохз 
Зегуег 2003 (выполняющая П$6) или УЛадо\з Зегуег 2008 (выполняющая П$ 7). Причина 
этой рекомендации объясняется ниже. 

Обратите внимание, что сама платформа АЗРМЕТ МУС не включена в список тре- 
бований к серверу. поскольку устанавливать ее отдельно не придется. Все, что нужно 
будет сделать — это поместить сборку Зузеет. Мер .Мус. 911 (“ М1схозоЕЕ.Мер.Мус. 911, 
если она используется) в папку \©1п. Это сделано для облегчения развертывания, осо- 
бенно в сценариях виртуального хостинга (ЗВагеа Воз 15), по сравнению с тем, когда 
нужно устанавливать сборки в глобальный кэш сборок (САС) сервера. Если на сервере 
нет .МЕТ 3.5 $Р1, понадобится также поместить в папку \Ь1п собственные копии сбо- 
рок бузтет. Иер .Аюзехасе1опз.911 и Зузеет.Иеь .Вопе1па. 911. Далее в главе эти шаги 
описываются более подробно. 
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Иногда требуется развертывать приложения АЗРМЕТ МУС на сервере Ппих или Мас 
ОЗ Х сиспользованием проекта с открытым исходным кодом Мопо (Мопо уже достаточ- 
но хорошо поддерживает АЗРМЕТ 2.0). На момент написания книги было трудно заста- 
вить АЗРМЕТ МУС корректно работать под управлением Мопо, и ввиду того, что данная 
тема представляет лишь незначительный интерес, она не рассматривается в этой главе. 
Дополнительные сведения можно получить по адресу "ми .попо-рго)есе.сощ/. 


Требования для виртуального хостинга 


Чтобы развернуть приложение АЗРМЕТ МУС на виртуальном веб-хосте, регистраци- 
онная запись на хосте должна иметь доступ к АЗРМЕТ 2.0, а на сервере должна быть 
установлена платформа .МЕТ Егате\хогК версии 3.5. Это все, что нужно. Искать по- 
ставщика услуг хостинга, который предлагает специальную поддержку АЗРМЕТ МУС, 
не понадобится. поскольку МУС ЕгатеуогКк можно развернуть самостоятельно, просто 
поместив необходимые сборки в папку \Б1п. 

Если у поставщика услуг хостинга сервер И$ 7 функционирует в стандартном ре- 
жиме Пфебтавеа Ррешпе (Интегрированный конвейер}, то чистые ОВТ, без расширений 
можно использовать без каких-либо проблем. Случай с П$ 6 рассматривается в разделе 
“Развертывание на сервере ПФ 6 в среде УЯпдо\уз Зегуег 2003” далее в этой главе. Если 
хост не установит схему сопоставления с подстановочными знаками, то ОВГ. должны 
будут содержать расширения вроде „.азрх. 


Основные сведения о серверах И$ 


П$ — это веб-сервер, встроенный в болыпинство выпусков операционной системы 
УЯлао%\з. 


® Версия 5 встроена в ОС УЛл4о\уз Зегуег 2000. Однако „МЕТ Егатез\хогК 3.5 не под- 
держивает УЛодо\уз Зегуег 2000, так что развертывать в этой среде веб-приложе- 
ния АЗРМЕТ МУС не получится. 


® Версия 5.1 встроена в ОС УЯпао%\з ХР РгоЕзз1юпа!. Однако сервер П$ 5.1 предна- 
значен для использования только во время разработки и не должен применяться 
в качестве рабочего сервера. 


е Версия 6 встроена в ОС МЯпао\мз Зегуег 2003. 


® Версия 7 встроена в ОС УЙЯп9ао\жз Зегуег 2008 и в выпуски ОС УЛпао\з Ува 
Визлез$ /Еал\мегризе/ОШптаее. Однако УЛоЧо\з Ува является клиентской опера- 
ционной системой и не оптимизирована для серверных рабочих нагрузок. 


® Версия 7.5 встроена в ОС УЙпао\уз Зегуег 2008 К2 и УЙадо\з 7. 


Итак, почти наверняка рабочим веб-сервером будет П$ 6 или П$ 7.х. Основное вни- 
мание в настоящей главе уделяется именно этим двум вариантам. Сначала будет кратко 
изложена теория, положенная в основу веб-сайтов ПЗ. виртуальных каталогов. привя- 
зок и пулов приложений. После этого будет показано, как внутренний механизм обра- 
ботки запросов П$ влияет на возможность использования ОБТ, без расптирений. 


Веб-сайты и виртуальные каталоги 


Все версии П$ (кроме 5.1) допускают размещение нескольких независимых веб-сай- 
тов одновременно. Для каждого веб-сайта должен быть указан корневой путь (папка 
в файловой системе сервера или общий ресурс в сети), и тогда ПЗ будет обслуживать 
любое статическое или динамическое содержимое, которое найдет в этой папке. 
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Для направления входящих НТТР-запросов определенным веб-сайтам в И$ потребу- 
ется сконфигурировать привязки (Ы1пан193). Каждая привязка отображает все запросы 
с конкретной комбинацией [Р-адреса, номера порта ТСР и имени хоста НТТР на опреде- 
ленный веб-сайт (рис. 14.1). Дополнительные сведения о привязках будут даны ниже. 


в ' Мер $Иез 


НИея т. © = Зои бюирья Мо Боурто я 


Мате Ю Чаше Ваау Ра 


2. безый 2еБ ЗЕ №  5%оррей “В ННру веру ЭфетЕВе юр... 
$ РеЕ оте 2 Заией  дммребястехогт оп ^:80 Ниру мБ Рес 

$2 СеНеде 3 айеф 80 Пир аБола тес оНее 
Ве 4  Бзиед ВЕ Нар ЗАлев РАУСТе 


Рис. 14.1. Диспетчер служб ИЗ отображает список одновременно разме- 
щенных веб-сайтов вместе с их привязками 


В качестве дополнительного уровня конфигурирования в любом месте иерархии па- 
пок сервера можно добавлять виртуальные каталоги. Каждый виртуальный каталог за- 
ставляет ПЗ извлекать содержимое из какого-то другого файла или сетевого ресурса и 
обслуживать его так, будто бы оно действительно присутствует в виртуальном каталоге 
под корневой папкой веб-сайта (рис. 14.2). Это несколько напоминает ярлык папки в 
УЛпа0%5 или символическую ссылку в 1Апих. 
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Мей ие РеЧег 
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Рис. 14.2. Отображение виртуальных каталогов в диспетчере служб 1$ 7 
(в режиме просмотра содержимого} 


Каждый виртуальный каталог при желании можно пометить как независимое при- 
ложение. В этом случае он получает собственную конфигурацию приложения, и если 
содержит в себе приложение АЗРМЕТ, то становится независимым от состояния роди- 
‘тельского веб-сайта. В нем даже может выполняться другая версия АЗРМЕТ, отличаю- 
щаяся от родительского веб-сайта. 

В ПЗ 6 было введено понятие пулов приложений как механизма обеспечения более 
надежной изоляции между различными веб-приложениями, работающими на одном 
веб-сервере. Каждый пул приложений запускает отдельный рабочий процесс, который 
может выполняться с различной идентичностью (что затрагивает уровень привилегий 
для доступа к лежащей в основе ОС} и определяет правила максимального использо- 
вания памяти, процессора, расписаний повторного использования процессов и тд. 
Каждый веб-сайт (или виртуальный каталог, помеченный как независимое приложение) 
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назначается какому-то пулу приложений. Когда одно из приложений терпит крах, это 
никак не влияет ни на сам веб-сервер, ни на другие пулы приложений. 


Привязка веб-сайтов к именам хостов, 
|Р-адресам и портам 


Поскольку на одном сервере может быть размещено множество сайтов. нужна ка- 
кая-нибудь система распределения входящих запросов по соответствующим сайтам. 
Как упоминалось ранее, каждый сайт можно привязать к одной или более комбинаций 
следующих параметров. 


» Номер порта (в производственной среде большинство веб-сайтов обслуживаются 
через порт 80). 


» Имя хоста. 


® 1Р-адрес (имеет значение, только когда сервер имеет более одного ТР-адреса, на- 
пример, при наличии нескольких установленных сетевых адаптеров). 


Имя хоста и ПР-адрес можно не указывать. Это создает эффект шаблона, позволяя 
сопоставлять с чем-то, не соответствующим конкретному веб-сайту. 

Если несколько веб-сайтов имеют одинаковую привязку. в любой определенный мо- 
мент времени может работать только одна из них. Виртуальные каталоги наследуют 
привязку своего родительского веб-сайта. 


Обработка запросов и обращение к А$Р.МЕТ сервером $ 


При обнаружении соответствия определенного веб-сайта конкретному запросу сер- 
веру ПЗ необходимо решить, как обрабатывать такой запрос. Должен он обслужить 
статический файл непосредственно с диска или же обратиться к некоторой платформе 
поддержки веб-приложений, которая вернет динамическое содержимое? Каким образом 
принимается решение? 

Разработчики веб-приложений АЗРМЕТ МУС должны понимать этот механизм, по 
крайней мере, на базовом уровне. В противном случае наверняка возникнут проблемы 
с отображением запросов на существующую конфигурацию марптрутизации. Об этом 
будет свидетельствовать ошибка 404 МоЕ Еоппа (не найдено). 


Обработка запросов серверами И$ 5, 15 би И$ 7, 
функционирующими в классическом режиме 


Кроме интегрированного режима П$ 7 (который будет описан ниже) имеется также 
классический режим П$, появивитийся в П$ 5. В этом режиме динамическое содержи- 
мое может обслуживаться только" за счет отображения файловых расширений ОВ! на 
расширения 1ЗАРГ. 

Сервер П$ извлекает растнирение имени файла из ОН! (например, расширение .азрх 
из ОВГ, Веер: //Бозераме/Ео19ет/{Е11е.азрх?Еоо=раг) и передает управление соответ- 
ствующему расширению [ЗАРГ. В П$ 6 отображение на расптирения ГЗАР! конфигуриру- 


На самом деле есть еще более старое средство ССТ (Сошизоп Сафе\мау Плейасе — общий 
шлюзовой интерфейс), но оно непригодно для хостинга приложений АЗРМЕТ. Для обработ- 
ки каждого запроса оно требовало бы запуска нового экземпляра СГВ, в результате чего 
катастрофически бы снизилась производительность. 


- Интерфейс Ииегпе! Зегусез АРТ ({ЗАР!) — это старый подключаемый механизм И$. Он позво- 
ляет выполнять неуправляемый код С/С++ из ОИ.-библиотек как часть конвейера обработ- 
ки запросов. 
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ется на странице Маррйодз (Отображения). Для открытия этой страницы щелкните пра- 
вой кнопкой мыши на веб-сайте в диспетчере служб П$ и выберите в контекстном меню 
пункт Ргорее$ (Свойства). Затем последовательно выберите значки Ноте Опестогу 
(Домашний каталог}, Сопйдиганоп (Конфигурация), Маррта5 (Отображения). В П$ 7 
можно воспользоваться страницей Нап ег Марртд$ (Сопоставления обработчиков}, 
которая показана на рис. 14.3. Для этого в окне диспетчера служб П$ выберите соот- 


ветствующий веб-сайт и дважды щелкните на значке Нап ег Марртоз (Сопоставления 
обработчиков). 
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Рис. 14.3. Страница сопоставления обработчиков в 1$ 7, позволяющая 
ассоциировать расширение .азрх с библиотекой азрпеЕ 1зар1.911 


Обращение к платформе А$Р.МЕТ 


Программа установки .МЕТ Егатемогк (или исполняемый файл азрпее хед113.ехе) 
автоматически настроит отображения *.азрх, *.аха, *.азйх и ряда других расшире- 
ний имен файлов на специальное раситирение ЕЗАР] под названием азрпее 15ар1.911. 
Именно так базовая платформа АЗРМЕТ вовлекается в обработку запроса; запрос дол- 
жен соответствовать одному из расширений имен файлов, и тогда сервер П$ обратит- 
ся к азрпее 1зар1.911, РИ.-библиотеке неуправляемого кода ГЗАРГ, которая передаст 
управление исполняющей системе АЗРМЕТ, размещенной МЕТ СТВ в другом процессе. 


Сложности, связанные с применением ЦВЕ без расширений 


Описанная выше система традиционно хорошо работает с серверными страницами 
АЗРМЕТ, поскольку на самом деле они представляют собой дисковые файлы с расши- 
рением „азрх. Однако она намного хуже подходит для новой системы маршрутизации, 
в которой ОБ! не должны соответствовать файлам на диске и часто вообще не имеют 
расширений имен файлов. 

Как известно, новая система маршрутизации строится вокругкласса модуля .МЕТНТТР 
по имени 0х1ВосЕ1п9Мода1е. Этот модуль НТТР должен рассматривать каждый запрос и 
принимать решение о передаче управления одному из классов контроллеров. Но посколь- 
ку это код МЕЛ, он выполняется только во время обработки запросов, предусматриваю- 
щих использование АЗР.МЕТ (т. е. тех, которые в П$ отображаются на азрпее 1зар1.911). 
Следовательно, если запрошенный ОБН, не имеет соответствующего расширения име- 
ни файла, то азрпее 1зар1.911 не вызывается, а это значит, что также не вызывается 
Ох1ВочЕ1п9МодаТе, и сервер П$ просто попытается обслужить этот ОБТ, как статический 
файл с диска. Поскольку обычно такой файл на диске отсутствует возникает оппибка 404 
МЕ опа. Вот что может произойти с чистыми ОНТ, без расширений. 
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Поначалу с этой проблемой сталкиваются почти все, кому приходится развертывать 
приложение АЗРМЕТ МУС на сервере П$ 6. Далее в этой главе будут описаны четыре 
возможных решения. 


Обработка запросов в интегрированном режиме 1$ 7 


В сервере П$ 7 появился совершенно новый режим конвейера, который называется 
интегрированным режимом конвейерной обработки. В этом режиме „МЕТ является есте- 
ственной частью веб-сервера. В нем уже нет необходимости использовать расширение 
ТСАР! для вызова кода МЕТ, поскольку теперь сам П$ 7 может обращаться к модулям 
и обработчикам НТТР (например, классы „МЕТ, которые реализуют ТНЕЕрМоду1е или 
ТНЕЕрнапа1 ет) непосредственно из своих сборок „МЕТ. Разумеется. при желании можно 
пользоваться и старыми неуправляемыми растнирениями ГЭАР. 

Интегрированный режим по умолчанию включен для всех пулов приложений. 
Переключение пула приложений в классический режим (например, если есть унасле- 
дованные расширения 1ЗАР! или фильтры, которые не работают правильно в интегри- 
рованном режиме) осуществляется на странице конфигурации Аррйсаноп Рос!$ (Пулы 
приложений), показанной на рис. 14.4. 
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Рис. 14.4. Конфигурирование пула приложений для выполнения в интегрированном режиме 


Обращение к платформе А$Р.МЕТ 


Винтегрированном режиме сервер П$ по-прежнему выбирает обработчики (либо рас- 
ширения 1ЗАРТ, либо классы ТНЕЕрНапо1ех) на основе расптирений имен, извлеченных 
из ОВГ. Это также можно сконфигурировать на странице Нап ег Маррпд$. Отличие от 
классического режима состоит в том, что пропускать запросы через азрпеЕ_1зар1. 911 
больше не требуется; теперь можно иметь прямо отображение *.азрх на Зузсет. Мер. 
ОТ. РасдеНапа1ехЕаскогу — класс „МЕТ, отвечающий за компиляцию и запуск серверных 
страниц АЗРМЕТ \еБРогиз. Другие расширения АЗРМЕТ (такие как *.азВх) отобража- 
ются на другие классы ТНЕЕрНар91ех из МЕТ. После активизации АЗР.МЕТ на веб-сер- 
вере все отображения настраиваются автоматически. 


Упрощение обработки ЦВЕ. без расширений в интегрированном режиме 


Как известно, класс ТНЕЕрНапд1ех представляет конечную точку обработки запро- 
са, поэтому каждый запрос может быть обработан только одним таким обработчиком 
(которые определяется по раснтирению имени файла из ОВГ). Для сравнения, классы 
ТНЕЕрМоди1е включаются в конвейер обработки запросов, поэтому можно иметь любое 
количество таких модулей, участвующих в обработке одного запроса. В ПЗ 7 это верно 
даже для запросов, которые не обрабатываются в конечном итоге средствами АЗРМЕЛ. 

Поскольку Ох1ВоиЕ1р9Моди1е реализует интерфейс тНеерМоды1е (а не ТНЕЕрНар@1ет), 
он может участвовать в обработке всех запросов, независимо от расширений имен фай- 
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лов и отображений обработчиков. При вызове 0х1Воче1ра9Мода1е позволяет системе 
маршрутизации сопоставлять входящий запрос с активной конфигурацией маршрути- 
зации, и если находит подходящий для запроса элемент, то передает управление одному 
из классов контроллеров (или специальному обработчику ТБооееНапа1ех). 

Ох1ВоцЕ119Моди1е по умолчанию сконфигурирован на участие во всех запросах, по- 
тому что при создании нового пустого веб-приложения АЗРМЕТ МУС в файле меь. сопЕ19 
уже присутствует узел <зузфет.иербегуег>: 


<зузсем.мербетуехг> 
<пода1е5 хирА11МападейМода1е ЕохА11Бечиез&=="%гие"> 
<хгепоуе паще="б ск1реМода1е"/> 
<гетоуе пате="0Ох1ВоцЕ1п9Моди1е"/> 


<адЯ паме="5сх1рЕМодо1е" гсуре="бузфет. И р.Напа1етз .5ст1реМоди1е, ..."/> 
<а@а папе="Ох1ВочЕ1паМоди1е" Суре="ЗузЕет.Иеь .КоиЕ1п9.Ох1Воце1паМоди1е, ... "/> 
</поао1ез> 


</зузеещ.иеюбехуег> 


Узел <зузсем. Ее — это место, где сервер П$ 7 хранит конфигурационные 
данные для приложения?. Поэтому после развертывания веб- -приложения на сервере 
15 7 маршрутизация запросов без расширений сразу начинает работать, не требуя ни- 
какой дополнительной настройки. 


Обработка запросов веб-сервером, встроенным в Убиа! ЗшоГо 2008 


Вы уже наверняка заметили, что при запуске приложения (нажатием <Р5>) во встро- 
енном веб-сервере \1зиа] Зил@ю 2008, который называется иеБбаеу. иеБзегуех.ехе, 
система маршрутизации также работает. Причина в том, что иераеу.иебзегуег.ех 
обрабатывает все запросы через АЗРМЕТ, поэтому всегда будет вызываться модуль 
Ох1КоцЕ1п9Модо1е. Вас может ожидать неприятный сюрприз, когда вы позднее развер- 
нете приложение на сервер П$ 6 и обнаружите. что там все оказывается сложнее, чем 
было при разработке. К счастью, существуют решения этой проблемы. которые будут 
рассматриваться далее в главе. 


Развертывание приложения 


Развертывание приложения в основном означает копирование файлов на веб-сервер 
с последующей настройкой сервера П$ для их обслуживания. Разумеется. при наличии 
и другого компонента приложения, такого как база данных, также понадобится устано- 
вить и его, а также, возможно, развернуть схему данных и загрузить в нее начальную 
информацию. (Поскольку можно использовать любую систему управления базами дан- 
ных, эта тема не в настоящей главе не рассматривается.) 


Копирование файлов приложения на сервер 


Во время выполнения приложение АЗРМЕТ МУС использует в точности тот же набор 
файлов, что и традиционное приложение АЗРМЕТ“. 


® Скомпилированные сборки .МЕТ (те. те, которые хранятся в папке \61п). 


3 В отличие от ранних версий П$, в которых конфигурационная информация хранилась в от- 
дельной “метабазе”, которую не так-то просто развернуть. 


‘в проектах АЗРМЕТ МУС по умолчанию используется классическая модель предваритель- 
ной компиляции, доступная со времен АЗР.МЕТ 1.0, а не вариант динамической компиля- 
ции, который появился в АЗРМЕТ 2.0, но так и не обрел широкой популярности. Именно 
поэтому приложения АЗРМЕТ МУС не нуждаются в наличии файлов кода С# на сервере. 


Глава 14. Развертывание 469 


е Файлы конфигурации и настроек (например, иеб.сопЕтд и любые файлы 
*.зет(1193). 


е Нескомпилированные шаблоны представлений (*.азрх, *.азсх И * .тазтехг). 


® Файл с1ора1 .азах (который указывает АЗРМЕТ, какой скомпилированный класс 
представляет глобальный экземпляр НЕрАрр11саЕ1оп). 


е Любые статические файлы (например, графические изображения, файлы С$$ и 
Чауа$сиру. 


» Если приложение запускается в режиме отладки, то файлы *.раь из панки \р1т, 
содержащие дополнительную отладочную информацию (на рабочих серверах они 
развертываются редко). 

Перечисленные выше файлы должны быть развернуты на веб-сервере. К, ним не от- 
носятся файлы, которые касаются только аспектов разработки. К, тому ке, их лучше не 
развертывать, исходя из соображений безопасности. Таким образом, ниже перечислены 
файлы, которые не должны развертываться. 


® Файлы кода С# (*.сз, включая файлы отделенного кода, если они присутствуют 
в приложении). 


® Файлы проекта и решения (*.31п, *.510, *.с5рго) или *.сзрго- .изех). 
е Файлы из папки \05]. 


® Все файлы, имеющие отношение к системе управления версиями исходного кода 
(например, панки .зуп, если используется система ЗиБуегзюп, или *.зсс, если 
применяется \1зиа] Зоигсеба). 


Совет. Вместо ручного выбора и фильтрации файлов, подлежащих развертыванию, рассмотрите 
возможность добавления в систему управления версиями исходного кода автоматизирован- 
ного процесса сборки, который извлечет, скомпилирует и подготовит приложение к развер- 
тыванию. Популярным бесплатным вариантом является СилзеСотиго!.МЕТ (БЕЕр://сспек. 
тРосансиогКз .сом/). В качестве более быстрой, но менее мощной альтернативы можно ис- 
пользовать средство публикации (Рибй$П) из Мзиа! Зи 2008, о котором речь пойдет ниже. 


Развертывание сборок А$Р.МЕТ МУС и маршрутизации 


Все приложения АЗРМЕТ МУС зависят от трех сборок, помимо тех, что входят 
в состав „МЕТ 3.5: бузсет.Мер .Мус.911, Зузеем. Мер .Воце1п9.911 и бузфет. Мер. 
АБзЕгасЕе1опз.911. 

Поскольку эти сборки уже включены в САС рабочей станции (благодаря программе 
установки АЗРМЕТ МУС), приложение МУС может работать на рабочей станции без по- 
мещения этих сборок в папку \Ъ1п. Однако на рабочем сервере эти сборки не присутст- 
вуют в САС. Вы должны гарантировать возможность обнаружения развернутым прило- 
жением необходимых сборок платформы. Ниже описаны два способа, как это сделать. 


Способ 1: развертывание сборок платформы в папке \Ь1п 


В сценариях с виртуальным хостингом (когда внесение изменений на стороне сер- 
вера не разрешено) простейший выбор состоит в размещении необходимых сборок в 
папке \51п. Это проще всего сделать, заставив \У150а1 Эбаю копировать три сборки 
платформы в папку \53п при каждом построении приложения. В окне Зоа4оп Ехрогег 
раскройте узел ВеГегепсез (Ссылки), выберите эти три сборки, а затем в окне Ргорегиез 
(Свойства) установите параметр Сору 1оса! (Копировать локально) в Ткие. После пере- 
компиляции папка \Ю1п будет содержать копии этих сборок, так что они окажутся и на 
сервере, когда вы скопируете на него файлы приложения. 
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Способ 2: установка сборок платформы в САС сервера 


Если есть возможность установить .МЕТ 3.5 $Р1 на сервере, то так и сделайте. 
Этот пакет обновлений включает сборки Зузсеи. Мер .Вос1п4а.911 и Зузкем.Иеь. 
АБзегасЕ1Топз . 911, так что они попадут в САС и не придется развертывать их в папке 
\Ь1п. В качестве альтернативы можно установить их в САС, запустив программу уста- 
новки АЗРМЕТ` МУС на сервере. 


Где должно размещаться приложение 


Приложение можно развернуть в любой папке на сервере. При первой установке 
сервера П$ автоматически создается папка для веб-сайта по имени Ре \еь $це в 
с: \ ГреЕрчБ\имигоо{\, но размещать приложение именно в ней вовсе не обязательно. 
Нередко приложения размещаются на другом физическом носителе, те. не там, где 
установлена операционная система (например, ве: \иеБз1еез\ехатр1е.сов\). Выбор 
места полностью зависит от ваших предпочтений, но на него может повлиять плани- 
руемое резервное копирование сервера. 


Использование средства публикации в Миа! З{идто 2008 


В простейшем сценарии развертывания можно воспользоваться встроенным в \!з0а1 
Эна 2008 средством публикации (РиБИзБ) для переноса соответствующих файлов на 
веб-сервер. Этот инструмент может копировать файлы приложения в перечисленные 
ниже места. 


® Сервер ЕТР. 
® Локальный экземпляр П$. 


* Удаленный веб-сервер, на котором установлен пакет расширений ЕтопРаре Зегуег 
Ежеп$!01$. 


® Локальный/сетевой диск. 


Чтобы активизировать этот инструмент, выберите пункт меню Вийд»Риы 5! <имя 
проекта> {Построение=>Опубликовать <имя проектоа>). Откроется диалоговое окно РУБЕН 
М/еБ (Веб-публикация), показанное на рис. 14.5. Обратите внимание на возможность вы- 
бора в группе переключателей Сору (Копировать) варианта Оту Шез пеедед тю гип 115 ар- 
рйсаНоп (Только файлы, необходимые для запуска этого приложения), который позволит 
отобрать набор файлов, как описано выше. Этот переключатель по умолчанию выбран. 


$ Барсе теаязопниу еси оса осрйе 


СЯ 2} ененио Нез рис о роБнеБ 


1 Нес пееЗЕЯ 0 ря В зррНезося 
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Рис. 14.5. Средство публикации \Мзиа! Зи ю 2008 
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Даже если этот инструмент не удастся использовать для развертывания на конкрет- 
ном веб-сервере, все равно с его помощью файлы приложения можно скопировать в ло- 
кальную папку на рабочей станции. Для этого нужно будет удостовериться, что выбран 
переключатель ОтУу Нез пеедед №0 гип 115 аррИсаноп, и затем вручную перенести ре- 
зульгирующие файлы в выбранную папку на веб-сервере. 


Развертывание на сервере 1$ 6 
в среде \\Мпдом:$ Зегуег 2003 


Перед развертыванием приложения на сервере, функционирующем под управлени- 
ем ОС МЯпао\уз Зегуег 2003, понадобится установить П$ и .МЕТ Егатемюогк 3.5. Для ус- 
тановки П$ выполните следующие шаги. 


1. Запустите мастер Мапасе Хочг Зегуег (выбрав в меню За! (Пуск) пункт Мападе 
Уоцг Зегуег (Управление сервером). Если этот пункт меню З1фа отсутствует, то 
дважды щелкните на значке Адттигануе Тоо!$ (Администрирование) в панели 
управления. 


2. Щелкните на ссылке Ада ог гетоуе а годе (Добавить или удалить роль) и затем на 
кнопке Мех{ (Далее), чтобы пропустить начальную страницу мастера. Обнаружение 
сетевых настроек может занять некоторое время. 


3. Если мастер предложит выбрать между вариантами Тура! сопйдигаНоп ог а 
51 зегуег (Типичная конфигурация для первого сервера) и Сизют сопйдигайоп 
(Выборочная конфигурация), выберите вариант Сизют сопйдигаНоп и щелкните 
на кнопке Мех. 


4. Выберите в списке ролей сервера вариант АррИкайоп зегуег (1$, АЗР.МЕТ) (Сервер 
приложений (1$, АЗРМЕТ)) и щелкните на кнопке Мех{. 


5. Отметьте флажок ЕпаЫе АЗР.МЕТ (Включить АЗРМЕТ) и щелкните на кнопке Мех+. 
После просмотра итоговой информации о выбранных настройках еще раз щелк- 
ните на кнопке Меж, и система приступит к установке и конфигурированию П$. 


6. Щелкните на кнопке Ри И (Готово). 


Теперь загрузите пакет .МЕТ Егатехюогк 3.5 5Р1 из ВЕЪр: //зпа11ез Е ао$кртее.сой/ и 
установите его. Возможно, понадобится перезагрузить сервер. 

Удостоверьтесь, что сервер П$ установлен и работает, открыв браузер на сервере и 
перейдя но адресу Веер: //1оса1Воз®/. Должна отобразиться страница с заголовком 
“Опаег СопзгасНоп” (В разработке). 


Добавление и конфигурирование нового 
веб-сайта МУС в диспетчере служб И$ 


Скопируйте файлы приложения в какую-то папку на сервере, если это еще не сдела- 
но. Помните о необходимости копирования только тех типов файлов, которые необхо- 
димы для выполнения приложения (как было перечислено выше). 

Выполните следующие шаги, чтобы сконфигурировать ПЗ для обслуживания 
приложения. 


1. Откройте диспетчер служб Ц$, дважды щелкнув на значке АдтиттаНнуе Тоо|$ 
(Администрирование) в панели управления и затем выбрав соответствующий зна- 
чок в открывшемся окне. 


2. В древовидном представлении слева раскройте узел, представляющий сервер, а 
затем узел \\Меб Зйез (Веб-сайты). Щелкните правой кнопкой на любых элементах. 
которые не нужны (например, Гетацй \!еб йе (Веб-сайт по умолчанию), и выбе- 
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рите в контекстном меню пункт З\юр (Остановить) или Вее (Удалить), чтобы эти 
элементы не мешали в будущем. 


Добавьте новый веб-сайт, щелкнув правой кнопкой мыгли на узле \МеБ ЗНез и вы- 
брав в контекстном меню пункт Мем=\\еь Зйе (Создать Веб-сайт). Целкните на 
кнопке Мех{ (Далее), чтобы пропустить начальную страницу мастера. 


Введите описательное имя для веб-сайта (например, планируемое доменное имя) 
и щелкните на кнопке Мех{. 


. Введите подробные сведения о предполагаемых привязках к [Р-адресу, порту и 


имени хоста. Если это будет единственный веб-сайт на сервере, можно оставить 
без изменений все значения по умолчанию. Если планируется размещать не- 
сколько сайтов параллельно, следует ввести уникальную комбинацию привязок. 
Разумеется, для публично доступных Интернет-приложений имеет смысл указать 
порт ТСР по умолчанию, те. 80, в противном случае ОВГ, будут вызывать у посе- 
тителей неудобства. Щелкните на кнопке Мех+. 


. Укажите папку, в которой были развернуть файлы приложения (ту, где находит- 


ся файл ме. сопЕ1 а и подкаталог \Ъ11). Оставьте флажок А!о\м/ апопутоц$ ас- 
сез$ (Разрешить анонимный доступ) отмеченным, если только не собираетесь 
использовать компонент \Яп4о\з АиепйсаНоп (это не подходит для Интернет- 
приложений). Щелкните на кнопке Мех{. 


Укажите в качестве прав доступа Веад (Чтение) и Вуп $сИр!$ (Запуск сценари- 
ев). Выбирать право Ехесше не нужно (несмотря на упоминание 1ЗАР! в его опи- 
сании), потому что по умолчанию библиотека азрлеЕ_1зар1.411 помечена как 
“СПЕ епрте” (механизм выполнения сценариев}. Щелкните на кнопке Мех+, а 
затем на кнопке Рит5И (Готово). 


И, наконец, что очень важно, откройте диалоговое окно Ргорег!Чез$ (Свойства) для 
нового веб-сайта (щелкнув правой кнопкой мыши на имени веб-сайта и выбрав в 
контекстном меню пункт Ргоре@ез (Свойства)), перейдите на вкладку АЗР.МЕТ и 
установите для параметра АЗР.МЕТ уегзюп (Версия АЗРМЕТ) значение 2.0.50727. 


На заметку! Несмотря на то что приложения АЗРМЕТ МУС выполняются в среде „МЕТ Егаптемогк 3.5, 
все равно в качестве версии АЗР.МЕТ должна быть указана 2.0.50727. В действительности вы- 
бора между „МЕТ 3.0 и .МЕТ 3.5 не предусмотрено. Причина в том, что АЗРМЕТ 3.5 на самом 
деле использует ту же СЬВ-среду, что и АЗРМЕТ 2.0 (в АЗРМЕТ 3.5 имеется новый компилятор 
С# и новый набор сборок библиотеки классов платформы, но не новая СЫА-среда), позтому 
сервер 1$ не делает между ними различий. 


Проверьте полученную на данный момент конфигурацию. открыв браузер на сер- 
вере и зайдя на ВЕЁр://1оса1позЕ/ (возможно, этот ОБТ, понадобится подкорректиро- 
вать, если приложение было привязано к определенному порту или имени хоста или зке 
развернуто в виртуальном каталоге). Пока не используйте браузер на рабочей станции, 
поскольку если имеются какие-то ошибки, то полная информация о них может быть 
получена, только если браузер запущен на сервере. 

Если все работает правильно. появится домашняя страница сайта. Но хотя домаги- 
няя страница сайта функционирует нормально, следует проверить и прочие страницы. 
Сервер П$ 6 по умолчанию не поддерживает ОБТ, без расширений, и если именно они 
применяются на сайте, попробуйте посетить один из них. Скорее всего, при этом воз- 
никнет ошибка 404. Мот Еоипа, как показано на рис. 14.6. 

Еспи домашняя страница вообще не появилась, ниже отписано, что следует 
предпринять. 
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Рис. 14.6. Сервер 1$ 6 не обслуживает ОВЁ без расширений, 
если не проведено дополнительное конфигурирование 


Поиск и устранение неполадок 


Если домашняя страница сайта отображается при посещении корневого ЧЕ! (на- 
пример, Веер: //1оса1ЪозЕ/), можете перейти к следующему разделу “Обеспечение ра- 
ботоспособности ОВ! без расширений на сервере ПЗ 6”. Если же домашняя страница 
сайта не появляется. воспользуйтесь перечисленными ниже советами. 


® Если посещение корневого ОБТ, вызывает ошибку 404 М Еоцпа, ошибку с тек- 
стом “Отескюгу зб Оешеа” (Листинг содержимого каталога запрещен) или 
же возвращает действительный листинг каталога, то, скорее всего, приложение 
АЗРМЕТ МУС вообще не запускалось. Чтобы исправить это, выполните следую- 
щие действия. 


® Проверьте, входит ли файл РеЁай1%.азрх в список страниц содержимого по 
умолчанию. Для этого в окне диспетчера служб ПЗ щелкните правой кнопкой 
мыши на веб-сайте и выберите в контекстном меню пункт Ргорег@е$ (Свойства). 
На открывшейся странице перейдите по ссылке Воситещ$ (Документы) и убе- 
дитесь, что флажок ЕпаБе деГаий сотет раде (Разрешить страницу содержи- 
мого по умолчанию} отмечен. Если файл РеГаи1® .азрх отсутствует в списке, 
добавьте его туда. Для того чтобы установки вступили в силу. откройте окно 
командной строки и выполните команду 11зтезефе.ехе. 


® Если это не помогло, проверьте, включена ли платформа АЗРМЕТ на сервере г. 
В окне диспетчера служб П$ в списке \Меб Зегисе Ежепзюп$ (Расширения веб- 
служб) должна быть включена версия АЗРМЕТ %2.0.50727. 


» Если версия АЗРМЕТ %2.0.50727 отсутствует в списке расширений веб-служб. 
значит, либо не установлена платформа „МЕТ Егаше\мо1К, пибо она не ассоции- 
рована с сервером И$ (возможно, из-за того, что установка МЕТ 3.5 выполня- 
лась перед установкой ПЗ). Установите .МЕТ Егате\огк 3.5 или, если уже сдела- 
ли зто, запустите программу азрпее гед113.ехе -1, которую найдете в папке 
\ИТМРОЙМ 5 \МАскозоЕЕ .МЕТ\ЕтамемогКк\\у2.0.50727. 

Перечисленные выше действия также помогут разрептить некоторые ошибки 
типа 403 Ассезз Оешеа (доступ запрещен). 


Если используется Пиегиеё Ехрогег, убедитесь, что страница не кэширована в браузере. 
Нажмите <Е5> для ее обновления. 
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® Если получен “желтый экран смерти” АЗРМЕТ с сообщением “Рагзег Еггог Меззабе: 
Оптесобиме але фуре" (Оптибка разбора: неопознанный тип атрибута), то, 
скорее всего, по оптибке веб-сайт был сконфигурирован для выполнения версии 
АЗРМЕТ 1.1 (посмотрите, какая версия АЗРМЕТ указана в строке \Мегэюп пюгтаноп 
в нижней части страницы с ошибкой). В окне диспетчера служб ПЗ перейдите на 
вкладку АЗР.МЕТ и удостоверьтесь, что выбрана версия АЗРМЕТ 2.0.50727. 


° Если получен “желтый экран смерти” АЗР.МЕТ с сообщением “Рагзег Еггог 
Меззаде: СЬПа подез по аПо\еа” (Оштибка разбора: дочерние узлы не разрешены), 
то, возможно, что установлена и выбрана версия .МЕТ Егаште\могк 2 вместо МЕТ 
Егатехмогк 3.5. Установите ее. 


Обеспечение работоспособности ЦВЕ. 
без расширений на сервере И$ 6 


Как уже упоминалось ранее в этой главе, сервер П$ 6 не обращается к библиотеке 
азрпее_1зар1 .911 до тех пор, пока не распознает в ОВГ. расширения имени файла, ото- 
браженного на азрпее 15ар1.а11. Это значит что система маршрутизации (реализо- 
ванная в ТНЕЕрМод@о1е) не вызывается по умолчанию для ОБТ, без расширений или для 
ОЕ. с незарегистрированными расширениями (например. *.тхс). Вот почему в боль- 
нинстве случаев после развертывания приложений АЗРМЕТ МУС на П$ 6 поначалу воз- 
никает ошибка 404 №1 Коипа. В табл. 14.1 описаны четыре наиболее общих решения, 
каждое из которых подробно объясняется ниже. 


Таблица 14.1. Способы заставить работать систему маршрутизации на сервере 1$ 6 
ии 


Решение Преимущества Недостатки 
Использование схемы сопоставления Заставляет сервер 1$ обраба- Потенциально 
с подстановочными знаками тывать все запросы с помощью может снижать 
АЗРМЕТ производительность. 
Очень легко настраивается. 
Сохраняет чистые ОРЕ без 
расширений. 
Использование во всех маршрутах Легко настраивается. Портит чистоту ЦВЕ. 
традиционных расширений имен фай- Не приводит к снижению 
лов АЗРМЕТ. Добавьте .азрх ко всем производительности. 
шаблонам ЦАЕ вхождений маршрута Н бет 
(например, {сопехо11ех} .азрх/ ы а иМЕНЕНИЯ о 
{асЕ1оп}/ {194} }, вынудив И$ ото- ЕЕ. и подх -? 
бражать эти запросы на АЗРМЕТ, для виртуального хостинга). 
Использование во всех маршрутах спе- Относительно легко Портит чистоту ЧВЕ. 
циальных расширений имен файлов. настраивается. 
Теже действия, что ив предылущем ре- Не приводит к снижению 
шении, но вместо .азрх применяется производительности. 


„гус. Расширение .тус понадобится 
зарегистрировать на сервере $ (объ- 
яснения даются ниже). 


Использование перезаписи ОРЕ. Это 
трюк, заставляющий ИЗ считать, что 
расширение имени файла есть, когла 
на самом деле оно отсутствует. 


Сохраняет чистые УР! без 
расширений. 


Не приводит к заметному сниже- 
нию производительности. 


Трудно настраивается. 


Требует использования 
стороннего продукта 
(хотя и бесплатного). 
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Использование схемы сопоставления с подстановочными знаками 


Это простейшее решение для обеспечения работы ОВГ, без расширений на сервере 
П$ 6, которое рекомендуется применять, если нет каких-то специальных требований. 
Оно заставляет ПЗ обрабатывать все запросы с использованием азрпеЕ 1зар+. 411, 
позтому независимо от того, какое расширение имени файла присутствует в ЧВЕ (или 
вообще никакого}, система маршрутизации всегда вызывается и передает управление 
соответствующему контроллеру. 

Чтобы настроить это поведение, откройте диспетчер служб ПЗ. щелкните правой 
кнопкой мыши на приложении или виртуальном каталоге и выберите в контекстном 
меню пункт Ргорегвез$ (Свойства). На открывшейся странице перейдите по ссылке Ноте 
Опесюгу=СопйдигаНоп (Домантний каталог»Конфигурация). Щелкните на кнопке пзей 
(Вставить) в разделе \Масага аррИсайоп тар (Схема сопоставления с подстановочны- 
ми знаками приложения), но не на кнопке Ада (Добавить), расположенной выше, и на- 
стройте новую схему сопоставления с подстановочными знаками, как описано ниже. 


» В поле ЕхесмаЫе (Исполняемый файл) укажите с: \"зпаоиз\и1 скозоЕЕ.пек\ 
Егапемотк\\2.0.50727\азрпее 1зар1.а11 или скопируйте и вставьте значение 
из поля ЕхесшмаЫЦе в существующей схеме сопоставления для расширения .азрх. 


» Снимите отметку с флажка \егИу Па! Ше ех!{5 (Проверять существование файла), 
поскольку ОВГ, без расширений не соответствуют реальным файлам на диске. 


Вот и вся установка! Теперь ОНТ. без распгирений должны функционировать корректно. 


Недостатки использования схем сопоставления с подстановочными знаками 


Поскольку теперь сервер П$ использует АЗРМЕТ для обработки всех запросов, расшире- 
ние азрпеЕ 15ар1.411 берет на себя ответственность даже за обработку запросов статиче- 
ских файлов, таких как графические изображения, файлы С5$ и файлы Зауа$сире. Система 
маршрутизации будет распознавать также и ОВ!,, которые соответствуют файлам на диске, 
и пропускать их (при условии, что параметр ВолеЕх1зе1т9Е41ез не установлен в Егое). 
После этого будет вызываться встроенный в АЗРМЕТ обработчик реЕаз1ЕНЕЕрНапд1ет для 
статической обработки файлов. В этом случае появляются две возможности. 


» Если вы перехватываете запрос (например, с использованием ТНЕЕрМодо1е или 
Арр11саЕ1оп Вед1пВедиезе ()) и затем отправляете некоторые НТТР-заголовки, 
модифицируете политику кэширования, производите запись в поток Везропзе или 
добавляете фильгры, то РеЕао1ЕНЕЕрНапа1ех обработает статический файл, пере- 
дав управление встроенному классу обработчика но имени З+а+1сЕ11еНапа\1ек. 
Это значительно менее эффективно, чем естественная обработка статических 
файлов сервером ПЗ: файлы не кэшируются в памяти, а каждый раз считываются 
с диска; не принимаются во внимание заголовки Саспе-Сопеко1 или заголовки, 
указывающие время истечения срока хранения в кэше, которые могли быть скон- 
фигурированы в П$, позтому браузеры не смогут правильно кэшировать статиче- 
ские файлы; не будет использоваться сжатие НТТР. 


® Если вы не перехватываете запрос, но модифицируете его, как было описано ра- 
нее, то РеЁаз1 ЕНЕЕрНапо1ек вернет управление обратно серверу П$ для обычной 
обработки статического файла. Это намного эффективнее, чем обработка с помо- 
ЩьЬЮ бтат1сЕ11еНапа1ег (в этом случае, например, отправляются корректные за- 
головки, указывающие время истечения срока хранения в кэше), но сохраняются 
затраты, связанные с переключением на управляемый код и обратно. 


6 На самом деле сервер ПЗ будет вызывать каждую схему сопоставления с подстановочными 
знаками по очереди, пока не обработает запрос. Встроенный обработчик статических фай- 
лов будет использоваться, только если не подойдет ни одна схема. 
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Если незначительное снижение производительности вас не беспокоит (скажем, 
потому, что зто приложение для корпоративной сети, которое обслуживает лишь не- 
большое количество пользователей), тогда можно остановить выбор на этом решении и 
удовлетвориться простой схемой сопоставления с подстановочными знаками. С другой 
стороны, если нужна максимальная производительность при обработке статических 
файлов, стоит обратиться к другим стратегиям развертывания, или, по крайней мере, 
исключить каталоги со статическим содержимым из схемы сопоставления с подстано- 
вочными знаками. 


Исключение определенных подкаталогов из схемы 
сопоставления с подстановочными знаками 


Для повышения производительности можно заставить сервер ПЗ исключить опреде- 
ленные каталоги из схемы сопоставления с подстановочными знаками. Например, если 
исключить каталог /СопЕепфе, то П$ станет обрабатывать все хранящиеся там файлы в 
обход АЗРМЕТ. К сожалению, средство исключения каталогов в диспетчере служб П$ не 
реализовано. Редактировать схемы сопоставления с подстановочными знаками можно 
только на уровне отдельных каталогов, непосредственно модифицируя метабазу с помо- 
щью такого инструмента командной строки, как аЯ9з0411 .353, который по умолчанию 
находится в с: \ТпеЕеруь\Ад1 и ск1рЕз\. 

Это довольно просто. Сначала в диспетчере служб П$ отыщите числовой идентифи- 
катор приложения, как показано на рис. 14.7. 


ИУ НЕ ув л безгуке (115 Мой з9ех 


(пбенлеЕ ТлРонтафоп эем 


+ \И2ООЗУЕНМЕР (са! сотрикег) В мусёрр 105364569 Рипойа 
3 | РТР 565 {| 68 мина (5юрре) 1184318079 5орре4 
#1 Аррисамоп РооБ 3] мире 1819014142 Экоррей 


1 МБ Зея 


Идентификатор 


| 


__› азрпеЕ сйепе РР 
в ых НЕ .. 


те Е 2 


Рис. 14.7. Использование диспетчера служб $ 6 для определения числового 
идентификатора веб-сайта 


Затем откройте окно командной строки, перейдите в каталог с: \Тпефраь\ 
Ааилибсктрез и выполните следующую команду: 


а950е11.56$ ЗЕТ /И35УС/105364569/хоое/Сортепе /5ск1рЕМарз "" 


В приведенной команде 105364569 необходимо заменить конкретным числовым 
идентификатором приложения. Эта команда позволит исключить все схемы сопостав- 
ления с подстановочными знаками (и не с подстановочными знаками) для каталога 
/Сопфепе, так что все файлы в нем будут обрабатываться встроенными средствами П$. 
Естественно, вместо /СопеепЕ можно подставить путь к любому другому каталогу. 


Совет. Если вы предпочитаете использовать для исключения каталогов из схемы сопоставления с 
подстановочными знаками диспетчер служб ИЗ, а не команду аази%11 .л65, то и это возможно, 
хотя и слегка нестандартно. Сначала необходимо пометить каталог /Сопеепе как “приложе- 
ние” (щелкните на нем правой кнопкой мыши, выберите в контекстном меню пункт Ргорег@ез 
(Свойства), на открывшейся странице перейдите по ссылке Ринестогу (Каталог) и щелкните 
на кнопке Стеа{е (Создать)). После этого диспетчер служб 1$ позволит редактировать схемы 
сопоставления с подстановочными знаками для данного каталога, так что можно будет удалить 
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схему сопоставления с азрпеЕ _1зар1 .911. И, наконец, вернитесь на страницу Отесюгу и 
снимите пометку “приложение” с каталога, щелкнув на кнопке Ветомуе (Удалить). Изменения, 
внесенные в схемы сопоставления с подстановочными знаками для данного каталога, останут- 
ся в силе, даже несмотря на то, что диспетчер служб 15 больше не позволит увидеть настройки 
для зтого каталога. 


Использование традиционного для АЗР.МЕТ расширения имени файла 


Если наличие расширений .азрх в ОВ! не планируется, такое решение настроить 
очень просто, и оно не помешает обработке сервером П$ статических файлов. Просто 
добавьте .азрх непосредственно перед косой чертой во всех элементах маршрутов. 
Например, шаблоны ЧВГ, могут выглядеть следующим образом: {сопехго11ег} .азрх/ 
{асЕ1оп}/{1а} или муарр.азрх/ { сопето11ет} / {асЕ1оп}/{1а}. Конечно, в равной 
степени можно указать и любое другое расширение файла, зарегистрированное для 
азрпее 1зар1.4911, скажем, .азнх. После внесения изменений понадобится переком- 
нилировать и развернуть обновленные файлы приложения на сервере. 


На заметку! Не заключайте расширение .азрх вместе с именами параметров в фигурные скобки (те. 
не пытайтесь использовать в качестве шаблона УВЕ {сопетго11ег .азрх}) ине вставляйте .азрх 
вкакие-либо значения РеЕаз1+4 $ (например, не устанавливайте { сопеко11ех = "Номе.азрх" }). 
Причина в том, что расширение .азрх не является частью имени контроллера, и оно должно 
присутствовать только в шаблоне ОВЕ для удовлетворения требований сервера 15. 


При таком подходе отпадает необходимость в схеме сопоставления с подстановочны- 
ми знаками. Это значит, что расширение азрпеЕ 1зар1. 411 будет вызываться только 
для запросов, адресованных приложению, но не для запросов статических файлов (ко- 
торые имеют другие расптирения). К сожалению, при этом нарупается чистота ЧВГ. 


Использование специального расширения имени файла 


Если ОБТ, должны оснащаться расптирением .ихс вместо .азрх (или еще какое-ни- 
будь расширение}, то это организовать несложно при условии, что поставщик услуг 
хостинга предоставляет доступ к диспетчеру служб ПЗ для регистрации специальных 
расптирений ГАР. 

Обновите все шаблоны ЧК! в элементах маршрута, как было описано ранее в раз- 
деле “Использование традиционного для АЗРМЕТ расптирения имени файла”, но вместо 
.азрх укажите собственное расширение. Затем после перекомпиляции и развертыва- 
ния обновленных файлов на сервере выполните перечисленные ниже действия, чтобы 
зарегистрировать специальное расптирение имени файла в П$. 

В окне диспетчера служб ПЗ щелкните правой кнопкой мыши на виртуальном ката- 
логе и выберите в контекстном меню пункт Ргорее$ (Свойства). Затем последователь- 
но выберите значки Ноте Опесюгу (Домашний каталог), СопНдигайоп (Конфигурация). 
Щелкните на кнопке Ада (Добавить) в разделе АррИсайоп ефепзюп$ (Расширения при- 
ложения) и определите новое отображение следующим образом. 


® В поле ЕхесаЫе (Исполняемый файл) укажите с:\и1пдоиз\иаскозоЕЕ. пее \ 
Ехашемокк\у2.0.50727\азрпеЕ 1зар1.911 или скопируйте и вставьте значение 
из поля ЕхесщаЫе в существующей схеме сопоставления для расптирения .азрх. 


» В поле Ежепзюп (Расширение) введите .пус (или другое распгирение, которое хо- 
тите использовать для элементов маршрутизации). 


® Вразделе \ейо$ (Команды) оставьге выбранным переключатель АН уепо$ (Все коман- 
ды), если только не планируется специальным образом фильтровать НТТР-методы. 
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° Оставьте отмеченным флажок ЭсИр епоте (Механизм сценариев), если только 
для приложения уже не предоставлена привилегия Ехесще (Выполнение), тогда 
состояние зтого флажка не играет роли. 


° Удостоверьтесь, что флажок Ме у {Па{ Ше ехё51 (Проверять существование файла) 
не отмечен, поскольку ОКИ. не соответствуют действительным файлам на диске. 


° Щелкните на кнопке ОК и продолжайте щелкать на ОК, пока не будут закрыты 
все окна свойств. 


Теперь должна появиться возможность открыть страницу по адресу БЕЪр: //1осаТозе/ 
воте/1п4ех .тус (или по другому адресу, который соответствует новой конфигурации 
маршрутизации) в браузере на сервере. 

Не удаляйте существующее отображение для .азрх, поскольку оно по-прежнему не- 
обходимо для обработки страницы -/регаи1%.азрх, которая требуется для обращения 
к АЗРМЕТ при запросе корневого ОВГ. 


Использование перезаписи ЦВЕ 


Это определенно самое сложное в настройке решение, но и единственное, которое 
обеспечивает обработку ОНТ, без расширений и не требует для зтого схему сопоставле- 
ния с подстановочными знаками. Преимущество данного подхода состоит в том, что 
статические файлы (например, файлы с расширениями *.сзз, *. Эред) из любого ка- 
талога будут обработаны средствами сервера ПЗ, без участия азрпее 1зар1.911, в то 
время как ОВ!, без расширений — встроенными средствами АЗРМЕТ. 


На заметку! Добавление подобной сложности к действующим серверам не рекомендуется. Так сто- 
ит поступать лишь тогда, когда не удается достигнуть адекватной производительности обслужи- 
вания статических файлов с использованием схемы сопоставления с подстановочными знаками 
и исключением каталогов. Данное решение рассматривается только для полноты картины. 


Трюк сводится к выполнению следующих действий. 


1. Когда на сервер поступают запросы без раситирения, с помощью фильтра ГЗАРГ 
от независимых разработчиков должна производиться перепись ОБГ, со вставкой 
какого-то расширения АЗРМЕТ (например, .азрх). Сервер П$ обнаружит расши- 
рение и отобразит его на азрпее 15ар1.911, а, следовательно, на АЗРМЕТ. 


2. Перед проверкой ЧЕ, системой маршрутизации обработчик Арр11сае1 оп _ 
Вед1пВечиез® () должен перезаписать ОВГ, восстановив его первоначальный вид 
без расптирения. Система маршрутизации обнаружит первоначальный ОВГ. без 
расширения и направит его по соответствующему маршруту. 


Существует очень мощный продукт, выполняющий такую перезапись ОБТ, под 
названием ТЗАРГ ВехтгИе (иии.Ве11сопеесь .соп/). Это коммерческий продукт, но 
на момент написания настоящей книги была доступна и его бесплатная версия 
[БАР Кеулие Ге 2, которая отлично справляется с решением задачи перезаписи 
ОВЕ. После загрузки и установки 1ЗАР!_ВемтНе Ге 2 на сервере (с обязательным пе- 
резапуском П5) отредактируйте его конфигурационный файл (выбрав в меню {ам 
(Пуск) пункт А! Ргоогатз$=>Нейсоп®1ЗАР!_Вемийе> Ира. (Все программы®Нейсоп= 
ТЗАРГ Вемлие> Веера. 1п1)}, добавив в него следующие строки: 


$ Если приложение размещено в виртуальном каталоге, удалите символ комментария 
+ с приведенных ниже строк и укажите путь к виртуальному каталогу 
#От1МаесьРкеЕ1х /тмууакеа1к 

+От1ЕогиаеРкеЕ1х /туу1кеа1к 
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# Добавьте к этому правилу расширения, которые не должны обрабатываться АЗР.МЕТ 
Вемк1ееВо1е (.*)\. (с33191Е|1рпа|)рея!1]ра!93|24р) $1.$2 [1,1] 

+ Интерпретируйте корневой ОБТ как /ПРеЁбаз1®е.азрх, 

# как это по умолчанию делается в 11$ 6 

Вемг1ееВи]1е / /РеЕап1.азрх [1] 

# Снабдите ОВ префиксами "кеитл®еп.азрх/", чтобы они обрабатывались АЗР.МЕТ 
Вемг1еево1е /(.*) /хемк1Ееп.азрх/$1 [1] 


После сохранения этого файла понадобится перезапустить сервер П$, чтобы измене- 
ния вступили в силу. Для перезапуска П$ откройте окно командной строки и выполните 
команду 11 згезеф .ехе. Это выполнит первое действие из двух описанных выше. Теперь 
АЗРМЕТ будет обрабатывать все запросы за исключением тех, что соответствуют спи- 
ску известных раситирений статических файлов. 

Для проведения второго действия добавьте в класс С1оБа1.азах.сз следующий 
обработчик: 


ргофесееЯ ухо1а Арр11саЕ1оп Вед1пВечиез® (ОБ]есЕ зепаег, ЕуепеАхоаз е) 
{ 
НЕБрАрр1са1опт арр = зепаег аз НЕрАрр11са®1оп; 
1Е (арр != по11) 
1Е (арр.Веаиезе.АррВе1а 1уеСигкепЕЕхесие1опЕ11еРатр == 
"-/гемхлЕееп.азрх“") 
арр.СопеехЕе.Вемг1еРа№ ( 
арр.Весаезе.0к1 .Ра ВАпаОцеку.Вер1Тасе ("/хемг1Е®еп.азрх", "") 


); 

} 

Если все сделано правильно, то ОВГ, без расптирений будут обрабатываться в отсут- 
ствие схемы сопоставления с подстановочными знаками, не влияя при этом на обработ- 
ку статических файлов. Если поначалу это не работает, проверьте, корректно ли указан 
путь к виртуальному каталогу в файле ВЕЕра. 111 пакета ТЭАРГ_ВезлКе, и при необходи- 
мости перезапустите П$ с помощью команды 11згезее.ехе. 


Внимание! Это решение затрагивает все приложения, развернутые на сервере. Вполне возможно 
возникновение хаоса, если на сервере имеется несколько приложений, пусть даже относящих- 
ся к разным пулам приложений. Для обеспечения перезаписи УВЕ. только в отдельном прило- 
жении или виртуальном каталоге понадобится коммерческая версия 15АР! ВемЁе. В качестве 
альтернативы можно было бы написать собственный фильтр 1ЗАР!, но это доступно только с 
применением неуправляемого кода С/С++. 


Развертывание на сервере 1$ 7 


Приложения АЗРМЕТ МУС намного проще развертывать на сервере П$ 7 в среде ОС 
МЯпао\уз Зегуег 2008, поскольку интегрированный режим ПЗ 7 позволяет системе маршру- 
тизации подключаться к обработке всех запросов, независимо от расптирений имен фай- 
лов, но при этом обрабатывать статические файлы встроенными средствами АЗРМЕТ. 

Для установки сервера ПЗ 7 в среде ОС УЯпао\з Зегуег 2008 потребуется выполнить 
следующие шаги. 


1. Откройте диспетчер сервера (Зегуег Мапарег), выбрав в меню З{а\ (Пуск) пункт 
Адтиттайуе Тоо!5=>Зегуег Мападег (Администрирование=>Диснетчер сервера). 


2. В древовидном представлении слева щелкните правой кнопкой мыши на папке 
Воез (Роли} и выберите в контекстном меню пункт АЗ Рое$ (Добавить роли). 
Если отобразится страница Ве@юге \ои Ведт (Прежде чем приступить), щелкните 
на кнопке Мех (Далее), чтобы пропустить ее. 
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.- В списке возможных ролей выберите Аррисайоп Зегуег (Сервер приложений). 


(Если в этот момент откроется окно со списком требований к установке ПЗ, щелк- 
ните на кнопке Ада Вецийед Реафигез (Добавить требуемые средства).) 1Целкните 
на кнопке Мех{. 


. Отобразится страница со сведениями о сервере ПЗ. Щелкните на кнопке Мех{. 


. Щелкните на флажке АЗР.МЕТ под заголовком АррИсаноп Оеу@ортепе (Разработка 


приложений) на странице Вое Зег/се$ (Службы ролей). Откроется всплывающее 
окно с списком других средств, необходимых для установки АЗРМЕТ: щелкните на 
кнопке АЯ Недитед Вое Зегмсе$ (Добавить необходимые службы ролей). 


. Проверьте список служб ролей и выберите те, что понадобятся приложению. 


Например, если планируется использовать компонент УЯп4о\%з Аифеписаноп, 
включите его сейчас. Не выбирайте лишние службы, которыми не будете пользо- 
ваться. Цель состоит в том, чтобы минимизировать “площадь поверхности” серве- 
ра’. Щелкните на кнопке Мех. 


. На странице подтверждения просмотрите список средств и служб, которые долж- 


ны быть установлены, и затем щелкните на кнопке п${а! (Установить). После зто- 
го мастер установит П$ и активизирует АЗРМЕТ. 


По завершении установки щелкните на кнопке С!05е (Закрыть) на итоговой 
странице. 


После этого можно протестировать работу установленного сервера П$, открыв брау- 
зер на сервере и посетив ОВЁ БЕфр://1оса1позЕ/. Должна отобразиться страница с 
приветствием и логотипом П$ 7. 

Далее можно загрузить и установить платформу „МЕТ Егате\огк 3.5. 


Добавление и конфигурирование нового 
веб-сайта МУС на сервере 1$ 7 


Если зто еще не было сделано. сконируйте файлы приложения в некоторую папку на 
сервере. Не забудьте, что должны включаться только те типы файлов, которые необхо- 
димы для выполнения приложения (они перечислялись ранее]. 

Выполните следующие шаги, чтобы сконфигурировать сервер ПЗ 7 для обслужива- 
ния приложения. 


1. 


Откройте диспетчер служб ПЗ. дважды щелкнув на значке АЧпипхга{\уе Тоо!$ 
(Администрирование) в панели управления и затем выбрав соответствующий зна- 
чок в открывшемся окне. 


. В древовидном представлении слева раскройте узел, представляющий сервер, а 


затем узел ЗИез$ (Сайты). Щелкните правой кнопкой на любых элементах, которые 
не нужны (например. Ое!аи{ \еб $Ве (Веб-сайт по умолчанию)}, и выберите в кон- 
текстном меню Беве (Удалить) для их удаления. Чтобы только остановить эле- 
менты, выберите их и щелкните на ссылке Эюр (Остановить) в панели справа. 


. Добавьте новый веб-сайт, щелкнув правой кнопкой мыши на узле Эйез и выбрав в 


контекстном меню пункт Ада \еб Зйе (Добавить веб-сайт). Введите описательное 
имя в поле 5йе пате (Имя сайта) и укажите физический путь к папке, в которую 
были помещены файлы приложения. Если необходимо его привязать к определен- 
ному имени хоста и порту ТСР, введите эти сведения. По завершении щелкните 
на кнопке ОК. 


7 Частично это позволит защититься возможных уязвимостей в скрытых средствах и службах 
05$. Что более важно — снизится вероятность непреднамеренного нарушения конфигурации 
сервера, открывающего сервер в болыпей степени, чем необходимо. 
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На заметку! По умолчанию сервер И5 для добавленного веб-сайта создаст новый пул приложе- 
ний с тем же именем, что и этот веб-сайт. Запустите исполняющую среду .МЕТ СЕВ 2.0 (она 
необходима для приложения АЗРМЕТ МУС]) 8 и активизируйте интегрированный режим 15$ (это 
также нужно). При желании новый веб-сайт можно поместить в тот же пул приложений, что и 
существующий веб-сайт, если в этом пуле также выполняется среда .МЕТ СИВ 2.0. 


После этого все должно заработать. В интегрированном режиме система маршру- 
тизации работает без каких-либо проблем, так как модуль Ох] Воч1рамМоди1е по умол- 
чанию активизирован в файле иеь. сопЕ19 приложения. Проверьте работоспособность 
приложения, открыв браузер на сервере и посетив ОКГ, БЕр: //лоса1тозЕ/ (в случае 
привяэки к определенному порту или имени хоста или при развертывании в виртуаль- 
ном каталоге понадобится соответствующим образом подкорректировать ОВ). 

Если используется классический режим (вместо интегрированного), потребуется 
обеспечить корректную работу системы маршрутизации, как было описано ранее для 
сервера ПЗ 6. 


Совет. Если браузер отображает ошибку “Рагзег етог теззаде: Соша по! !оа4 Ме ог аззет у 
‘Зущет.Соге”” (Ошибка разбора: не удается загрузить файл или сборку бузкем.Соге}, зна- 
чит, платформа „МЕТ 3.5 не была установлена. Загрузите и установите ее. 


Дополнительные сведения о развертывании на сервере И$ 7 


Несмотря на то что приложения АЗРМЕТ МУС, скорее всего, сразу же заработают 
на сервере ПЗ 7, существует еще несколько моментов, которые следует принимать во 
внимание. 


® Анонимная аутентификация по умолчанию включена. Если это не то, что вам нуж- 
но, выберите веб-сайт в диспетчере служб ПЗ, откройте страницу АшШпепйсаноп и 
просмотрите конфигурацию. Например, если используется УЯаао\уз АиепбсаНоп 
и необходимо принудительно аутентифицировать все запросы, анонимную аутен- 
тификацию следует отключить. За дополнительными сведениями по настройке 
аутентификации обращайтесь в главу 15. 


® Если используется интегрированный режим и есть любые классы ТНЕЕрМодо1е 
или ТНЕЕрНап Тег, зарегистрированные в узле <зузеет.иер> файла иеь.сопЕ1с, 
например: 
<зузбетм.меб> 
<ВЕЕрНарЯ1]ет5> 
<а@9 уехр="*" раёф="*.Б1аь" уа11да+е="Еа1зе" 
фуре="МуМусАрр .Му5брес1а1Напа1ех, МумусАрр"/> 
</БЕЕрНап Я 1етз> 
<ВЕЕРМоди1ез$> 
<а9а пате="МунЕЕрМоди1е" Еуре="МумусАрр .МунЕЕрМоаа1е, МУМусАрр" /> 
</БЕЕрМмоди1ез> 
</зузеем.меб> 


8 Это не опечатка: когда идет речь о сервере П$. приложения АЗРМЕТ МУС выполняются под 
управлением исполняющей среды „МЕТ СТК 2.0. Помните, что версии .МЕТ 3.0 и МЕТ 3.5 по- 
прежнему работают с СГВ-средой из МЕТ 2.0. Именно позтому отсутствует выбор МЕТ 3.0 
или .МЕТ 3.5. Однако установка платформы „МЕТ 3.5 на веб-сервере все равно нужна. по 
скольку она включает новый компилятор АЗРХ и множество новых библиотек классов. ко- 
торые важны для нравильной работы приложения. 
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то их функционирование на встроенном сервере \1зна] Зала!ю 2008 не означает их 
работу на П$ 7. Эти классы должны быть также зарегистрированы в новом узле 
<5узеем.иербегуег>. Для этого понадобится либо воспользоваться страницами 
модулей и сопоставления обработчиков в диспетчере служб П$, либо отредакти- 
ровать файл меь. сопЕ19 вручную, обращая внимание на слегка отличающийся 
синтаксис: 
<зузЕет.мербегуег> 
<уа11ЧаЕ1оп уа11ЧасеТтеедгакедМодеСопЕ1дигае1от="егие" /> 
<поаи1ез гипА11МападедМоди1езЕогА11Ведиезез="Егие"> 
<а99 папе="МунЕЕрМо@и1е" 
фуре="МуМусАрр .МуНЕЕрМо4и1е, МуМусАрр" /> 
</пода1ез> 
<рап@Я1ет5> 
<а@а папе="МуНапа1ех" раёк="*.Б1аь" уехь="*" 
фуре="МУМусАрр .Мубрес1а1НапЯ1ех" /> 
</Вапд1ег$> 
</зузеет.мебекуег> 


В интегрированном режиме П$ 7 принимаются во внимание только те модули и об- 
работчики, которые зарегистрированы в узле <зузеещ.меббегуехк>. Если оставить 
любые обработчики и модули в узле <зузЕет.меб>, возникнет ошибка с сообщени- 
ем ‘Ап АЗРМЕТ зе пр Ваз Бееп Чеесе4 паё 40е$ поЁ арру ш Пицебгаеа тапабеа 
рареНпе тоде” (Обнаружена настройка АЗРМЕТ, не применимая в интегрированном 
режиме управляемого конвейера). В таком случае потребуется либо удалить старую 
регистрацию модуля/обработчика, либо добавить установку уа11ЗаеТитедкатеа 
МодеСопЕ19атга&1оп=" а] зе" в узел <зузеем.иер$егуег>/<уа11даЕ1оп>. Это по- 
зволит серверу П$ 7 просто игнорировать старые регистрации". 


® В интегрированном режиме П$ 7 появились и другие существенные изменения. 
К счастью, они затрагивают лишь немногие приложения АЗРМЕТ МУС. С длин- 
ным списком этих скрытых и низкоуровневых изменений можно ознакомиться по 
адресу ВЕЕр: //Е1пуиг1 . сом/З7ауас. 


Подготовка приложения к работе 
в производственной среде 


Существование различий между средой разработки и производственной средой 
сервера неизбежно. Вряд ли кому-то понравится в день развертывания приложения у 
заказчика обнаружить, что одно из таких различий мешает корректному функциони- 
рованию приложения. Лучитий способ избежать этого нежелательного сценария — не 
дотягивать до срока сдачи приложения в эксплуатацию. а вместо этого начинать вы- 
полнять развертывание рано и делать это часто в процессе разработки, возможно. с 
первой недели кодирования. Это не только обеспечит правильную работу без неприят- 
ных сюрпризов, но также даст возможность получать ранние и регулярные отклики на 
этапе разработки приложения. 

Чтобы не зависеть от обычно существующих различий между средой разработки 
и реальной производственной средой, код должен работать с путями файлов, конфи- 
гурацией маршрутизации, строками подключения к базам данных и прочими частям 


9 Это удобно в ситуации, когда необходимо, чтобы один и тот же файл имею. сопЕ1а применял- 
ся на сервере Н$ 7 (в интегрированном режиме), на встроенном веб-сервере \Изиа! Зааю и 
на сервере Н$ 6. 
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конфигурации через соответствующие уровни абстракции. Ради удобства такие уровни 
абстракции встроены в саму платформу АЗРМЕТ, поэтому нужно лишь знать, как ими 
пользоваться. 


Поддержка изменяемой конфигурации маршрутизации 


Никогда не следует жестко кодировать ОНТ, в ссылках и перенаправлениях. В про- 
тивном случае после изменения конфигурации маршрутизации эти ОБТ. станут недей- 
ствительными. На момент развертывания сайта могут появиться причины изменения 
конфигурации маршрутизации (например. понадобится добавить раснитирения имен 
файлов, чтобы удовлетворить требованиям П$ 6). Жестко кодировать не рекомендуется 
даже косую черту (/) в качестве ОВГ, домашней страницы, потому что после разверты- 
вания в виртуальном каталоге, это также будет нарушено. 

Вместо этого ЧВТ. должны генерироваться с использованием встроенных в плат- 
форму методов, таких как НЕм1.Асс1отЬ1пК(), Ох1.Асетоп (), Нем1 .Вед1иРогю() и 
Вед1хесЕТодАсЕ1оп (). Эти методы всегда учитывают действующую конфигурацию мар- 
шрутизации. 


Поддержка виртуальных каталогов 


Другое преимущество применения НЕг1 .АсЕ1опт11Кк() и других методов генерации 
ОКЕ связано с тем, что они автоматически адаптируются к развертыванию приложения 
в виртуальном каталоге. 

Также следует соблюдать осторожность при обращении к статическим файлам. Не 
кодируйте абсолютных ЧВ!, а используйте пути относительно приложения. Например, 
не включайте следующего в шаблон представления: 


<зСЕ1рЕ згс="/сопеепе/шузст1 рез. ]3"></зск1ре> 


Взамен пинтите так, чтобы это работало независимо то того, развертывается прило- 
жение в виртуальном каталоге или нет: 


<8се1рЕ эхс="<$= 0х1 .Сопеепе ("-/сопеепЕ/музсг1рез.]$") $>"></зск1рЕ> 


На заметку! УРЕ, которые начинаются с тильды (-), называются виртуальными путями. Символом 
тильды обозначается корневой каталог приложения, которым может быть и виртуальный ката- 
лог. Браузеры не распознают виртуальные пути и тильды в УВЕ, поэтому с помощью вспомога- 
тельного метода 0х1 .СопЕепе () они должны быть преобразованы в абсолютные пути. 


Дела обстоят немного сложнее, когда статические файлы сами содержат ссылки на 
другие статические файлы. Например, пусть имеется файл С$$, в котором присутствует 
ссылка на графическое изображение: 


БаскКагоипЯ-—1паде: их] (/сопеепЕ/1тадез/дхад1ете.91Е); 


Если приложение будет развернуто в виртуальном каталоге, зта ссылка будет нару- 
шена, и применять встроенные методы генерации ОБТ. или виртуальные пути в стати- 
ческом файле С5$ не получится. Единственное решение состоит в использовании отно- 
сительного пути, например: 


раскагоипЯ-1таде: их1(../сопЕеп& /1тадез/дка1ете.91Е); 


Помните, что браузеры интерпретируют ссылки в файле С$$ относительно этого 
файла, а не относительно НТМГ-страницы, в которую включен файл. 
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Использование средств конфигурирования АЗР.МЕТ 


Базовая платформа АЗРМЕТ предоставляет хороший выбор средств конфигурирова- 
ния, как простых, так и сложных. Не храните конфигурационные данные приложения 
в реестре сервера (это создаст трудности с развертыванием и применением системы 
управления версиями исходного кода). Кроме того, не храните также конфигурацион- 
ные данные в специальных текстовых файлах (которые потребуется вручную разбирать 
и кэшировать). Вместо этого облегчите себе работу, воспользовавнтись встроенным 
АР!-интерфейсом МебСопЕ19ха&1опМапвадег. 


Совет. АР!-интерфейс меьСоп Етдиха Е 1опМападехг отлично подходит для чтения конфигураци- 
онных установок из файла меЪ . сопЕт а — это намного проще извлечения конфигурационных 
установок из таблицы базы данных. Более того, МеЪСопЕ1дахаЕ1опМападег позволяет за- 
писывать изменения и новые значения обратно в файл иеЪ . сопЁ1 9. Однако из соображений 
производительности, масштабируемости и безопасности следует минимизировать количество 
операций записи изменений в мер . сопЕЁ1ч, а вместо зтого хранить часто изменяемые ус- 
тановки (такие как предпочтения пользователей) в базе данных приложения. АР!-интерфейс 
меЪСопЁ1диха&1опМападег лучше применять для установок, которые не изменяются меж- 
ду развертываниями, например, адреса серверов и дисковые пути. 


Конфигурирование строк соединений 


Многим веб-приложениям приходится работать со строками соединений с базами 
данных. Разумеется, они не должны жестко кодироваться в исходном коде — намного 
проще и удобнее хранить строки соединения в конфигурационном файле. В АЗРМЕТ 
предусмотрен специальный АР!-интерфейс для конфигурирования строк соединений. 
Если добавить следующие элементы в узел <соппесЕ10п5&х1193> файла мер .сопЕ13: 


<сопЁ1дакаЕ1от> 
<соппесЕ1оп5х1198> 
<а@а папе="Ма1ип0В" соппесЕ1оп5Ех1та=" Зегуег=шуЗегуег; Рабсафазе=зопейВ; „...“/> 
<аЯ папе="Аио1Е1п90В" соппесЕ1оп8Ех1п9="Зехуег=аиЯ101; Рабафазе=мурВ; ...“/> 
</соппесе1015%:1195> 
</сопЕ1докаЕ1оп> 


то их можно будет получить с помощью ИебСопЕ1дига&1олМападег .Соппес® 1081198. 
Нанример, ниже показан код для получения объекта ИМО ® ЗОГ. тина РакаСоп+ехк: 


зЕг1па соппесе1опбЕгтпа = ИебСсопЕ1аакае1опМападехг .Соппесе1оп5г1поаз ["МафпОВ"]; 
уаг дабаСопеехЕ = пем БабаСопеех® (соппесЕ1оп5Ех1п9д); 
Уаг ацеку = Екош сизбомех 1п дакаСопеех®.сееТаю1е<Соз®отек> () 

иреге // ... ит.д. 


На заметку! Если для создания экземпляров объектов доступа к данным используется контейнер 
юС, то обычно конфигурирование строк соединений (и любых других настроек компонентов 10С) 
можно производить с помощью этого контейнера. Такой подход рассматривался в главе 4. 


Конфигурирование произвольных пар “ключ/значение” 


Если нужен способ конфигурирования адресов почтовых серверов, дисковых путей 
или других простых значений, которые могут отличаться между средой разработкой 
и производственной средой, и если эти установки не должны производиться с помо- 
щью контейнера оС, можно добавить соответствующие пары “ключ/значение” в узел 
<аррЗеее1таз> файла мер .сопЁ19. Например: 
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<сопЕ1дигаЕ1от> 
<арр5ееЕ1т95> 
<адА кеу="па113ехуех" уа]1ае="зпёр .ехатр1е. сом" /> 
<а@Я Кеу="та11ЗекуегРог®" уа1ие="25"/> 
<ада кеу="орТоадедЕ11езР1хкесбогу" уа1ле="е: \меБ\Зафа\ир1оадедЕ11ез\"/> 
</арр5ееЕ1т9$> 
</сопЕ1дакаЕ1оп> 


Затем к этим значениям можно обращаться через ИерСопЕ1дихаЕ1отМапасдех. 
АррзееЕ1таз, как показано ниже: 


зЕг1па Бозе = МербопЕ1дакае1опМападех .Аррбее1п95 ["та115егуек"]; 
1пЕ роке = 116. Рагзе (МерСопЕ1диха&1опМападех. 
Арр5ееЕ1паз ["ма11бехуегРоге"]); 


Конфигурирование произвольных структур данных 


Иногда требуется настраивать более сложные структуры данных, чем простые пары 
“ключ/значение”. В предыдущем примере па115ехуег И па11ЗехуехРоге были сконфи- 
гурированы как два независимых значения, что не очень удобно, поскольку логически 
они представляют собой две части одной конфигурационной установки. 

Если необходим способ конфигурирования произвольных списков и иерархий струк- 
турированных настроек, можно начать просто с представления их в виде ХМГ свобод- 
ной формы в узле <сопЕ1дикаЕ1оп> файла иеь.сопЁ19. Например: 


<сопЁ1дига&1оп> 
<па113екхуех5> 
<зекуех Ноз&="этЕр1.ехашр1Те.сош" рохЕМонфек="25"> 
<изеРог Ядота1п="ехапр1е . сом" /> 
<изеЕог Яота1п="эфкаЕРЕ.ехатр1е. сом" /> 
<изеЕох допа1п="“а1ЕехпаЕ1\е .ехапр1е" /> 
</зекуех> 
<зекуегк розЕ="зтр2 .ехапр1е.сом" рог Митрегк="5870"> 
<изеРох ЯЧота4т="*" /> 
</зегуех> 
</па113екуег$> 
</сопЕ1аигаЕ1оп> 


Обратите внимание, что АЗРМЕТ не имеет встроенной концепции узла <па115егуегз> — 
это просто произвольный код ХМГ. 

Затем следует создать класс ТСопЕ1дикаЕ1отЗесе1опНапо1ек, который сможет ин- 
терпретировать этот ХМГ. Понадобится реализовать метод Скеафе (), который прини- 
мает специальные данные в виде объекта Хи1 Моде по имени зесЕ1оп и трансформирует 
их в строго типизированный резульгат. В приведенном ниже примере строится список 
объектов Ма11 бехуехЕпегу: 


ру611с с1аз5 Ма115екуекЕпеку 
{ 

рУчБ11с зЕх1па Нозбпаше { дек; зек; } 

руБ11с 1пЕ РохЕМомоехк { дее; зе; } 

рую11с 115%<5Ех119> Еохрома1тз { дее; зе б; } 
} 
рор11с с1азз Ма11ЗегуекСопЕ19Напд]1ек : ТСоп19дака1оптЗесЕ1опНапто1ех 
{ 

роь11с оБ]есе Схеаее (об]ес® рагепе, об)фесе сопЕ1дСопеехе, Хи Мойе зес®1оп) 

{ 

хекохп зесЕе1топ.бе1есЕМодез ("зегуег") .Сазф<Хи]1Моде> () 
.Зе1ес+ (х => пем Ма11ЗехуекЕтегу 


486 Часть ||. АЗРМЕТ МУС во всех деталях 


{ 
Нозепаше = х.АбЕк1рибсез ["розе"] .ТппегТехе, 
РокЕМатрек = 1те.Раг5е (х.Абестриеез ["рокЕМишьек"] .ТипехТех(), 
Еохгрота1пз = х.5е1есЕМодез ("изеЕохк") 


.Саз&<Хи]Моае> ()} 
.Зе1ест (у => у.Абег1риеез ["Зота1т"] .ТпрехтТехь) 
.Тор15 () 


}) . ТоГ1 зе (); 


} 


Совет. Начиная с версии АЗРМЕТ 2.0, вместо создания класса ТСоп1докаь1опзесь1опНапб1ехг 
можно воспользоваться более новым АР!-интерфейсом СопЕ1дихаетопЗесе1 оп. Он позволя- 
ет помещать атрибуты „МЕТ в оболочки конфигурационных классов, декларативно ассоциируя 
свойства класса с атрибутами конфигурации. Однако зтот новый АР!-интерфейс на самом деле 
увеличивает объем кода, который должен быть написан. Поэтому многие предпочитают реа- 
лизовывать ТСопЕ1дихае1оп5есе1опНапо1ег вручную и заполнять объект конфигурации с 
применением быстрого и злегантного запроса ИМО, как было показано выше. 


И, наконец, зарегистрируйте специальный раздел конфигурации и его класс 
ТСопЕ19икаЕ1оп5есЕ1опНапа1ет, добавив новый подузел в узел <сопЕ19зесЕ1опз> 
файла иеь. сопгЕ1 о: 


<сопЕ1аака&1оп> 
<сопЁ195есЕ1отз> 


<зесЕлоп паме="та115етуег5" буре="патезрасе .Ма115ехуекСопЕ1аНап1ег, аззепЬ1у“/> 
</сопЁ193есЕ1опз> 
</сопЕ1дака1от> 


После этого к конфигурационным данным можно обращаться в любом месте кода, 
используя метод МерСопЁ1 сита 1опМападех .сееЗесеЗолп (): 


1115Е<Ма115екуехЕпегу> зегуегз = 
УерСопЕ1диха{1опМападех . бесЗес®1оп ("па11$3егуегз") аз 1115Е<Ма11бетуетЕпеку>; 


Одна из замечательных особенностей метода МеьСопЕ 1дакаЕ1опМападех .сеебесЕ1оп () 
связана с тем, что он внутренне кэширует резульгат вызова метода Сгеате () реализа- 
ции ТСопЁ1дхае1оп5есЕ1опНаиа1ех, поэтому не повторяет разбор кода ХМГ, каждый 
раз, когда запросу нужен достун к определенному разделу конфигурации. 


Управление компиляцией на сервере 


Во время развертывания следует уделить особое внимание флагу дерод, который оп- 
ределен в узле <сопр11а&1оп> файла иер. сопЁ19: 
<сопЕ1адйгаЕ1оп> 
<зузеет.мер> 
<сошр11а1оп аебид="Екиае"> 


</сотр11а1оп> 
</зузфкет.мефб> 
</сопЕ1дакаЕ1оп> 


Когда механизм представлений У\еБЕогтз загружает и компилирует один из шабло- 
нов АЗРХ, согласно флагу дебод, он выбирает один из режимов компиляции: отладочный 
или выпуска. Если установка по умолчанию оставлена без изменений (дерод= "егие"), 
то компилятор сделает следующее. 
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®е Обеспечит возможность потагового выполнения кода, строка за строкой, за счет 
отключения ряда оптимизаций во время компиляции. 


» Компилирует каждый файл АЗРХ/АЗСХ отдельно по запросу вместо пакетной 
компиляции всех файлов в один прием (производя намного больше временных 
сборок, которые, к сожалению, потребляют больше памяти). 


» Отключает таймауты для запросов (позволяя тратить на запросы больше времени 
в отладчике). 


» Инструктирует браузеры не кэпировать статические ресурсы, обслуживаемые 
ИерКезочгсез .аха. 


Все это полезно во время разработки и отладки, но неизбежно отрицательно ска- 
зывается на производительности производственного сервера. Разумеется, при развер- 
тывании на рабочем сервере флаг дерад необходимо сбросить (дерид="Га1зе"). Если 
развертывание производится на сервере ПЗ 7, для редактирования этой и других уста- 
новок в файле иеЪ .сопЕ1 а можно воспользоваться инструментом конфигурации МЕТ 
Сотарйабоп (рис. 14.8). 


‚ вр МЕТ Согрйачоп 


} Варах  Епелёу Матлез ы 


В Вась 
Васи ОсизоНаНОя5 Те 
Нажилыгя Не ЗЫ Е 900 
Мая ве ОГВа В в 
Килесьи ВИилги 5 00:15:00 
В Вебамюог 
Рабе * 
Мигльег ОР Весогрйе5 15 
Че Ргаулая Раба 
лзна! Ваз ЧЕТ 
Е бепегй 
8 АззенлЬ Ея Уйпо В Аггау 
Сода Зыю ГИГЕССЕЕ 5ы1аой Атау 


БеГаый Рапачаде 6 
Теплрогаг; Отесвогу 


БеБьз 


Зресйес сотпрйавоп оР гей ог дебиз пана. СотрНез Чебиз Ыпапез И гие, 


Рис. 14.8. Использование инструмента конфигурации .МЕТ Сотрйайоп 
в 15 7 для отключения режима отладочной компиляции АЗРХ 


Обнаружение ошибок компиляции 
в представлениях перед развертыванием 


Как известно, файлы АЗРХ и АЗСХ компилируются на лету, когда на сервере возни- 
кает потребность в них. Они не компилируются в У1зиа] Эйлат, когда в меню выбира- 
ется пункт Вийа=>Вийа Зою#оп (Построить=?Построить решение) или нажимается кла- 
виша <Е5>. Обычно единственный способ проверить, что ни одно из представлений не 
вызывает ошибок компиляции, предусматривает систематическое посещение каждого 
возможного действия приложения и проверку возможности визуализации каждого дос- 
тупного представления. Если этого не делать, то существует опасность проникновения 
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синтаксических ошибок на производственный сервер, потому что какое-то конкретное 
представление не было проверено во время разработки. 

Для проверки всех представлений на предмет наличия ошибок компиляции можно 
включить специальную опцию проекта под названием МусВи11а\1емз. Откройте файл 
проекта АЗРМЕТ МУС (ВашеПриложение .сзрто)] в простом текстовом редакторе и изме- 
ните значение опции МусВи119\1ем5 с Еа1зе на $ кое: 


<МусвВи11ЧУ1еиз > гое</МусвВи119\У1еиз> 


Сохраните обновленный файл .сзрго) и вернитесь в \У1зиа! Зал. Теперь всякий 
раз при компиляции приложения среда \У1зпа1 За запустит послесборочный шаг, на 
котором скомпилируются все представления .азрх, .азсх и „.Мазкег с выводом всех 
возможных онптибок компиляции. 


Обнаружение ошибок компиляции в представлениях 
только при построении выпуска 


Имейте в виду, что включение упомянутого выше послесборочного шага заметно 
увеличит время компиляции, поэтому часто эта опция включается только при построе- 
нии выпуска. Это позволит перехватить ошибки компиляции перед развертыванием, не 
увеличивая время компиляции при повседневной разработке. 

Для этого откройте файл .сзрко) приложения в простом текстовом редакторе, най- 
дите в нем узел <Тахдеф> по имени АЕкегВи11а (ближе к концу файла) и затем измените 
атрибут Сопа1Е1оп следующим образом: 


<ТахдеЕ Маще="АЕесехВи114" Сопд1Е1оп=" ' $ (СопЕ1 очка оп) '=='Ве1еазе'!"> 
<АзрмеьСопр1 Тек У1есоа1Раеь="Еетр" Рьуз1са1Расв="$ (Рхо]есЕО1х) \..\$ (Рео]есЕМане) "/> 
</Тахдее> 


Обратите внимание, что после этого узел <МусВи1 1 9У1еиз> будет игнорироваться, и 
его даже вообще можно удалить. 


Резюме 


В этой главе рассматривались вопросы. которые обычно должны решаться при раз- 
вертывании приложения АЗРМЕТ МУС на рабочем веб-сервере. К, ним относится ус- 
тановка сервера ПЗ, развертывание файлов приложения и обеспечение нормального 
взаимодействия системы мартрутизации и веб-сервера. Несмотря на краткость, скорее 
всего, описано все, что необходимо знать в большинстве сценариев развертывания. 

Чтобы стать настоящим экспертом по П$, нужно знать намного болыше о монито- 
ринге работоспособности приложений, повторном использовании процессов, уровнях 
доверия, регулировании пропускной способности, использования процессора и памяти, 
и тд. Дополнительные сведения можно получить, обратившись к специальным ресур- 
сам, посвященным администрированию сервера ПЗ. 


ГЛАВА 15 


омпоненты 
платформы АЗР.МЕТ 


латформа АЗР.МЕТ МУС не проектировалась как автономное средство. Будучи 

платформой для разработки веб-приложений, большую часть своей функцио- 
нальности она наследует от лежащей в основе платформы АЗРМЕТ, которая, в свою 
очередь, базируется на самой среде .МЕТ ЕгатехгогК (рис. 15.1). 


Платформа АЗР.МЕТ 


Среда .МЕТ ЕгатемотК 


Рис. 15.1. Платформа АЗРМЕТ М\УС основана на более общей инфраструктуре 


Несмотря на то что такие встроенные в АЗРМЕТ МУС компоненты, как маршрутиза- 
ция, контроллеры и представления, являются достаточно гибкими, чтобы можно было 
реализовать почти любую часть необходимой инфраструктуры, останавливаться на ис- 
пользовании только их одних не всегда разумно. Значительная часть работы уже сдела- 
на другими, и вы можете воспользоваться готовыми решениями, если будете знать, как 
применять все богатство экономящих время средств. Следует помнить о существовании 
двух проблем. 


® Знание возможностей платформы. Разработчики часто попадают в ситуацию, 
когда тратят дни и недели на изобретение блестящей инфраструктуры аутенти- 
фикации и глобализации, пока какой-нибудь доброжелательно настроенный кол- 
лега не укажет на то. что нужное средство уже имеется в АЗРМЕТ, и его необходи- 
мо лишь активизировать в файле иеь .сопЕ19. Надо же! 


® Понимание, что это не платформа МеБКогт$. Большая часть инфраструктуры 
была спроектирована с учетом \еБЕогил$, поэтому не все здесь чисто транслиру- 
ется в новый мир МУС. Хотя одни средства платформы работают без проблем. 
другие требуют непростой подгонки и поиска обходных путей, а третьи вообще 
уже не применимы. 
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Цель настоящей главы — предложить решение обеих проблем. Вы узнаете о наибо- 
лее часто используемых средствах платформы АЗРМЕТ, которые важны для приложе- 
ний МУС, а также получите советы и подсказки по преодолению проблем совместимо- 
сти. Даже ветераны АЗРМЕТ наверняка найдут здесь нечто такое, что не использовали 
ранее. В этой главе рассматриваются следующие вопросы. 


» Аутентификация — механизмы УЙодо\з Аиеп{саНоп и Еогил$ АифепНсаНоп. 
® Система членства (МешфегзЬ1р)}, ролей (Ко!ез) и профилей (РгоН]е$). 

» Авторизация. 

® Кэширование данных. 

® Карты сайтов (для целей навигации). 

® Интервационализация. 


® Средет: ва мониторинга и повышения производительности. 


Перед тем, как приступить. следует отметить один важный момент: настоящая гла- 
ва не претендует на то, чтобы служить исчерпывающим справочником по всем этим 
средствам — это связано с ограниченным объемом. Здесь вы найдете описание базового 
применения каждого средства в контексте МУС, а также обсуждение возможных специ- 
фичных для МУС проблем. Данного материала должно быть достаточно для принятия 
решения о том, подходит ли данное средство. Чтобы получить дополнительные сведе- 
ния, необходимо обратиться к какому-нибудь руководству по платформе АЗРМЕТ 3.5, 
в частности, к книге Мэтью Мак-Дональда и Марио Шпушты Месгозой АЗРМЕТ 3.5 с 
примерами на С# 2008 для профессионалов, 2-е издание (ИД “Вильямс”, 2008 г.). 


Компонент МИпаом$ АшмпепёсаНоп 


В терминологии программного обеспечения аутентификация (ан епйсаНоп) озна- 
чает установление личности пользователя. Она совершенно отличается от авториза- 
ции (аи ой2а@оп), под которой понимается определение действий. которые разрешено 
делать конкретному пользователю. Авторизация обычно происходит после аутентифи- 
кации. Соответственно, средство аутентификации АЗРМЕТ касается только безопасной 
идентификации посетителей сайта с установкой контекста безопасности, в котором 
можно рептить, что позволено делать посетителю. 

Простейший способ проведения аутентификации предусматривает делегирование 
этой задачи серверу ПЗ (но, как будет объясняться ниже, это подходит только при- 
ложениям для корпоративных сетей). Это делается указанием компонента УЯлао\гз 
АиепйсаНоп в файле меЪ.сопЕ1с: 


<сопЕ1дакае1оп> 
<зузеем.меб> 
<азЕВепе1са1оп поде="Изпаомз" /> 
</зузЕет.меб> 
</сопЕ1дикаЕ1оп> 


После этого платформа АЗРМЕТ будет полагаться на сервер П$ при установке кон- 
текста безопасности для входящих запросов. ПЗ может аутентифицировать входящие 
запросы по списку пользователей, известных домену УЛп4о\з, или по списку сущест- 
вующих локальных регистрационных записей пользователей на сервере, применяя 
один из следующих поддерживаемых механизмов. 


» Анонимная аутентификация (апопутои$ аийепйсаНоп). Посетитель не должен 
вводить какие-либо регистрационные данные. Неаутентифицированные запросы 
отображаются на специальную учетную запись анонимного пользователя. 
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Базовая аутентификация (Бас ашпепйсайоп). Сервер использует протокол базо- 
вой аутентификации НТТР, описанный в документе ВЕС 2617, который заставля- 
ет браузер отобразить окно с предупреждением о необходимости аутентификации 
(АШПепйсаноп Ведигед). В этом окне посетитель должен ввести свое имя и па- 
роль. Введенные данные отправляются вместе с запросом в виде открытого тек- 
ста, поэтому базовую аутентификацию НТТР следует использовать только через 
безопасное соединение $$1.. 


Дайджест-аутентификация (@9е3Ё аи епйсайоп). В этом случае сервер также 
заставляет браузер отобразить окно с предупреждением о необходимости аутен- 
тификации (Ашпепбсаноп Вецииеч), но на этот раз регистрационные данные пе- 
ресылаются в виде шифрованного безопасного хеша, что удобно при отсутствии 
соединения 551. К, сожалению, этот механизм работает только с веб-серверами, 
которые одновременно являются контроллерами домена, к тому же только с брау- 
зером пиегпей Ехргег (версии 5.0 или более поздней). 


Встроенная аутентификация (й4едгое4 аитепйсаНоп). Сервер использует прото- 
кол аутентификации Кегфегоз версии 5 или МТМ для прозрачного установления 
личности пользователя, вообще не требуя ввода регистрационных данных. Этот 
режим аутентификации работает прозрачно лишь в ситуации, когда клиентская 
и серверная машины находятся в одном и том же домене УЙЛпао\уз (или в разных 
доменах, для которых сконфигурированы доверительные отношения). Если это не 
так, отображается окно АШпепйсайоп Вецииед. Данный режим широко использу- 
ется в корпоративных сетях, но не очень подходит для пользователей, работаю- 
щих через публичные сети вроде Интернета. 


Включить любой перечисленный выше механизм аутентификации можно с помощью 
диспетчера служб ПЗ 6 (в разделе Ампепйсайоп ап4 ассезз согёго! (Аутентификация 
и управление доступом) на вкладке Онефогу Зесийу (Безопасность каталога) окна 
Ргорегиез$ (Свойства)) или инструментом конфигурирования аутентификации ИЗ 7, по- 
казанном на рис. 15.2. 


___ № впаЫе алолугтрцз эссе 
Ива Не Робота МИпдон$ изер ассоупЕРог апопутоц$ аесе55: 


Хх 


ре АиепЯсаНов 


бисирЬи Ме бесириа =: 
пасте: 145Е_\№2КЗУМ Вгоиже... т = 
ай ы => о ее Нате Зни5 Везрспее Гуре 
. а ь 
Раззики 1 ооо Апспугоиз мрепясавоп ЕраБей 
ЯЗРАЧЕТ нпрезспаная Безе 
Башю Аиепнсаной ВззЫеа НТТР 401 Спайепде 
Бней дыкнеп{саной БызЫе$ НТТР 401 СраНепоЕ 
оВувеласатей ассезз” ое ь ы Роге Аыфепасаной ВззЫеф НУР 392 Росии Жедтех 
ее Залифольз Выбненесабст ЕизЫеа НИР СРаНепае 


р 


58 ое ацбнелсавол Рог ®лкуия Фот зегуег 
1% Вазе амнепёсавог (раззииог 5 егЕ и Чеаг 6ехЕ) 


Е 


- апопутоне ассес5 {5 Чкаей, су 
= 800855 15 ГЕЗИСЕ по МТЕ5 ассезх согто] Е 


МЕТ Раззрое анвейнеаНог 


сы | в | 
а 


они анны одни вонь олтаыь ль даны ином ленин ина шие 


Рис. 15.2. Экраны конфигурирования аутентификации для 1$ 6 (слева) и 1$ 7 (справа) 
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На заметку! Если при использовании 1$ 7 некоторые из названных механизмов аутентификации не- 
доступны, их понадобится включить на сервере. Для зтого щелкните на значке Ргодгат$ ап 
Реафигез (Программы и компоненты) в панели управления. В открывшемся окне щелкните на 
ссылке Тигп \М/паом/$ Теафигез оп апа оН (Включение или отключение компонентов МИпдо\$), 
раскройте ветвь \1егпе{ пптаНоп Зегусез$ (Службы 15}, затем ветвь \М/ойа \Млае \М/ер 
Зеглсез (Службы Интернета) и отметьте флажок возле элемента Зесиййу (Безопасность). 


Компонент УЙЯп9о\гз Аитепйсайоп обладает рядом очевидных преимуществ. 


» Его настройка не требует больших усилий и в основном сводится к конфигури- 
рованию сервера ПЗ. Кроме того, не придется реализовывать пользовательский 
интерфейс входа и выхода для разрабатываемого приложения МУС. 


® Поскольку используются централизованные регистрационные данные из домена 
\УЛп90%г$, администратору нет необходимости в поддержке отдельных наборов ре- 
гистрационных данных, а пользователям не нужно запоминать еще один пароль. 


® При использовании встроенной аутентификации пользователям даже не потре- 
буется вводить пароль, а их личность устанавливается безопасным образом без 
необходимости в наличии соединения $$. 


Ключевое ограничение компонента УЙп4ао\у$ АитепйсаНоп состоит в том, что обыч- 
но он подходит только для приложений корпоративной сети, так как у каждого пользо- 
вателя должны быть в наличии отдельные регистрационные записи в домене \Япдо\уз 
(очевидно предоставлять такие записи каждому, кто вошел из Интернета, нецелесооб- 
разно). По той же причине не следует предоставлять возможность самостоятельной ре- 
гистрации для новых пользователей или изменения паролей для существующих. 


Предотвращение или ограничение анонимного доступа 


При использовании компонента УЙЛп4аомз Ашеп@сайоп, например, в приложении 
для корпоративной сети. расположенного в домене \Йпао\х$. часто имеет смысл требо- 
вать аутентификацию для всех запросов. В этом случае посетители постоянно остаются 
в системе, а свойство Озех. ТаепЕ16у .Мате всегда будет заполнено именем учетной за- 
циси посетителя в домене. Чтобы обеспечить такое поведение, в П$ понадобится отклю- 
чить анонимный достун (см. рис. 15.2). 

Однако если нужно разрешить неаутентифицированным пользователям обращаться 
к определенным компонентам приложения (вроде домашней страницы сайта), но тре- 
бовать аутентификацию УЙпао\гз для доступа к другим частям приложения (скажем, 
к административным страницам), сервер П$ необходимо сконфигурировать так. чтобы 
позволить и анонимный доступ, и один или более других вариантов аутентификации 
(см. рис. 15.2). В таком случае анонимный доступ будет считаться доступом по умолча- 
нию. Аутентификация будет осуществляться в следующих ситуациях. 


1. Посетитель обращается к ОБТ, для которого сконфигурирована основанная на ОВ 
система авторизации АЗРМЕТ — Ок1АсЕВог1 ха 1опМодо1е, — которая не разреша- 
ет доступ анонимных посетителей. Это приводит к выдаче сервером ответа НТТР 401, 
заставляющего браузер выполнить аутентификацию (при необходимости открывая 
окно АМПепйсайоп Нецийеч). Как будет показано ниже, основанная на ОНТ, авто- 
ризация обычно является неудачным выбором для приложения АЗРМЕТ МУС. 


2. Сервер пытается обратиться к файлу, защищенному с помощью списка контроля 
доступа (ассезз сопёго! НЕ — АСЕ) УЯпдоууз, а АСЕ запрещает доступ к любой иден- 
тичности, для которой была разрешена анонимная аутентификация. Это также 
заставляет сервер ПЗ вернуть ответ НТТР 401. Для приложения АЗРМЕТ МУС 
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списки АСТ, можно использовать только для управления доступом к приложению в 
целом, а не к отдельным его контроллерам и действиям, потому что контроллеры 
и действия не соответствуют файлам на диске. 


3. Посетитель обращается к контроллеру или методу действия. оснащенному фильт- 
ром АЗРМЕТ МУС по имени [АсЕБог12е]. Этот фильтр авторизации отклоняет 
анонимный доступ, посылая обратно ответ НТТР 401. Дополнительно модно ука- 
зывать и другие параметры, ограничивающие доступ для определенных пользова- 
тельских учетных занисей или ролей, как более подробно описывалось в главе 9. 
Ниже приведен простой пример: 


ро611с с1аз5 НощеСопеко11ек : СопЕко11ек 
{ 
// Разрешает анонимный доступ 
раю11с Асе1опВези1е Тпраех() {... } 
// Сначала потребовать аутентификацию, затем авторизовать по роли 
[АсеБох1 хе (Ко1ез="Адтат") ] 
рУ9Ь11с Асё1опВези1е Зомеею1т9Тирохеат® (} { ... } 
} 


4. В приложении имеется специальный фильтр авторизации или какой-то другой 
специальный код, который возвращает НЕЕрОпасЕВог1хеВези1& или в против- 
ном случае приводит к выдаче ответа НТТР 401. 


Наиболее удобными для приложений АЗРМЕТ МУС являются последние два вариан- 
та, поскольку они предоставляют полный контроль над тем, к каким контроллерам и 
действиям разрешать анонимный доступ, а к каким — только через аутентификацию. 


Компонент Еогт$ АШПеписаНоп 


Компонент, реализующий аутентификацию УЙЯпао\з (\Йпао\з Аитепйсайоп), обыч- 
но подходит только для приложений корпоративной сети, поэтому в АЗРМЕТ предусмот- 
рен и более широко используемый механизм аутентификации, который называется ау- 
тентификацией с помощью форм и реализован в виде компонента Еоглз Аитепй_сайоп. 
Он единственный подходит для применения в Интернете. поскольку он взаимодейству- 
ет не с одними лишь регистрационными записями в домене \Лпдо\г$, а с произвольным 
хранилищем регистрационной информации. Такая аутентификация требует немного 
болыше работы по настройке (понадобится предоставить пользовательский интерфейс 
для входа и выхода посетителя), но обеспечивает гораздо большую гибкость. 

Поскольку протокол НТТР не поддерживает состояние, то посетитель, зарегистри- 
рованный в последнем запросе, не может рассчитывать, что сервер будет помнить его 
при следующем запросе. Как это принято во многих системах веб-аутентификации. в 
Еогилз Адфепйсайол для сохранения состояния аутентификации между запросами ис- 
пользуется механизм соо е-наборов браузера. По умолчанию применяется соо е-набор 
по имени .АЗРХАОТ (полностью независимый от соове-набора АЗР.МЕТ_Зезз1опта, ис- 
пользуемого для отслеживания сеансов). Если просмотреть содержимое соое-набора 
.АЗРХАОТ!, можно увидеть строку, подобную показанной ниже: 


90С50274С662470986Арр690704ВЕ652Е40ЕЕС3035ЕС19013726А22Е794В3558778В12Е7 


9985282Е84034р79С0А09рА2580007627739АЕЭЕСАЗАР4В786618008В4119р0072А8А700093 
5ААЕ7Е309С081Е28 


1 В браузере Енеюх 3 выберите в меню пункт Т00!5>ОрНопз (Инструменты Настройки}, пе- 
рейдите на вкладку Риуасу (Приватность) и щелкните на кнопке ЭНом/ Соокез (Показать 
СооК1е5). Откроется окно со списком соо е-наборов, установленных каждым доменом. 
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Строка выглядит не слишком понятно. Но если передать эту строку в качестве па- 
раметра методу КогтзАмеВеп®1саЕ1от .Рескур* (), она будет преобразована в объект 
Зузфет. Мер .3Зесик1®у . ЕохизАчеБепе1са 1опТлсКее со свойствами, перечисленными 
в табл. 15.1. 


Таблица 15.1. Свойства и значения расшифрованного объекта 
ЕогизАинВеп®1са®1опТ1сКее 


Свойство Тип Значение 

Мапе 5Ег1п9 "5феуе" 

СооклеРаЕН 5109 ум 

Ехр1каЕ1оп РафеТ1те {08/04/2009 13:17:55} 
Ехр1геа Боо1 Га15е 

ТзРегз1зферЕ Боо1 Га1зе 

Тэзоерафа РасеТлпе {08/04/2009 12:17:55} 
Озеграфа ЕЕ па м 

Уегз1оп ТЕ 2 


Самым важным из этих свойств является Маше, представляющее имя, которое 
Роги Аифепйсайоп назначит интерфейсу ТРу1пс1ра1 потока обработки запроса (дос- 
тупному через Озег. ТаепЕ1%у). Он определяет имя текущего зарегистрированного 
пользователя. 

Разумеется. для расшифровки значения соое-набора требуется секретный ключ 
<пасв1пеКеу> из файла меь .соп{1а”. и зто является основой безопасности Еогиз 
АнФепйсавоп. Поскольку посторонним ключ <паср1пеКеу> не известен, никто не смо- 
жет самостоятельно построить корректное значение .АЗРХАОТН. Единственный способ 
получить его — зарегистрироваться через страницу входа, указав правильные реги- 
страционные данные, и тогда Еогилз АлепйсаНоп выдаст действительное значение 
.АЗРХАОТН. 


Настройка Еогт$ АщпептесаНоп 


При создании нового пустого приложения АЗРМЕТ МУС в шаблоне проекта компо- 
нент Рог$ Адфеп@сайоп по умолчанию активизирован. Для зтого в файл иеь. сопЕ19 
включены следующие строки: 


<ааВепЕ1са®1оп шоде="Еогиз"> 
<Еогиз 109100:1="-/Ассоспе/1од0р" Е1теоне="2880"/> 
</аосвепЕ1сае1оп> 


Эта простая конфигурация достаточно хороша для начала. Если понадобится более 
тонкий контроль над работой Еогплз Аиепйсайоп, взгляните на опции, перечисленные 
в табл. 15.2, которые можно применять в узле <Еогтз> файла ие. сопЁ19. 


2 Чтобы заставить Еогио$ АийзеписаНоп работать в Интернет-мире, понадобятся либо особые 
отношения родственности между клиентами и сервером, либо все серверы должны иметь 
одно и то же явно определенное значение <пасЬ1пекеу>. Такое случайное значение можно 
сгенерировать по адресу пер: //азрпеегезоигсез .сош/Е001$/Кеусгеафог.азрх. 
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Таблица 15.2. Атрибуты, которые можно конфигурировать в узле <Еогтз> 
файла меЪ . сопЕ1 9 


Параметр 


соокле1ез5 


Чотали 


Тоалп0т1 


папе 


раеь 


теао1тез ть 


5111 пдЕхруга 1оп 


Е1пеоце 


Значение по 
умолчанию 


Озереу1серРкоЁ11е 


/1о91п.азрх 


„АЗРХАОТН 


Ёа1зе 


фтое 


30 


Описание 


Пытается отслеживать аутентификацию между за- 
просами, не используя сооКе-наборы. Об этом речь 
пойдет ниже. 


Если установлен, назначает сооКе-набор аутентифика- 
ции заданному домену. Это позволяет разделять сооКе- 
наборы аутентификации между поддоменами (напри- 
мер, если приложение развернуто на милх .ехатр1е . 
сот, то для параметра аота1п следует установить 
значение .ехатрте. сом*, чтобы разделить сооКе- 
набор между поддоменами ехапр1е . сом). 


Когда компонент Роит$ АшйепйсаНол требует регист- 
рацию, он перенаправляет посетителя по этому УВЕ. 


Имя сооКе-набора, используемого для хранения би- 
лета аутентификации. 


Устанавливает сооКе-набор аутентификации для 
отправки только по УВЕ ниже указанного пути. Это 
позволяет развертывать множество приложений на 
одном и том же домене, не открывая сооКе-наборы 
аутентификации одних приложений другим. 


Если установлен в Е гое, то компонент Еогт$ 
Ашпепнсавоп пометит флагом “безопасный” свой 
сооКе-набор аутентификации. Для браузеров это яв- 
ляется рекомендацией передавать такой сооКе-набор 


только в зашифрованных З$Ё запросах. 


Если установлен в Е хое, то АЗРМЕТ будет обновлять 
билет аутентификации по каждому запросу. Это зна- 
чит, что он не устареет, пока не истечет количество 
минут, указанное в параметре с 1теочт, после по- 
следнего запроса. 


Длительность периода в минутах, по истечении ко- 
торого сооКе-наборы аутентификации устаревают и 
становятся недействительными. Обратите внимание, 
что зто соблюдается на сервере, а не на клиенте: за- 
шифрованные пакеты данных сооЧе-наборов аутенти- 
фикации содержат информацию о времени действия. 


* Обратите внимание на символ точки в начале строки. Он обязателен, поскольку спецификация НТТР требу- 
ет наличия в свойстве аота1п сооФе-набора как минимум двух точек. Это неудобно, если, скажем, во время 
разработки необходимо разделять сооке-наборы между ВЕЕр: / /з1ее1.1оса1позЕ/ и БЕЕр: //з1%е2. 
1оса1Тоз®/. В качестве обходного пути добавьте в файл \и1паонз\зузЕем32\Яг1уехз\еЕс\ВозЕ$ 
элемент, отображающий з1Ее1.1оса1Воз+е .аеу и з1Ее2 .1оса]1оз%.аех на 1Р-адрес 127.0.0.1. После 
этого можно указать для аота1 пт значение .1оса1Поз*.аех. 
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Внимание! Если вы хоть немного заботитесь о безопасности, то должны всегда устанавливать 
гечи1ге551 в Егое. На момент написания этой книги в мире превалировали нешифрованные 
публичные беспроводные сети и беспроводные сети МЕР (имейте в виду, что протокол МЕР 
небезопасен). Скорее всего, ваши посетители пользуются ими. Это значит, что когда сооКе- 
набор .АЗРХАОТН пересылается по нешифрованному соединению НТТР — либо потому, что 
так спроектировано ваше приложение, либо потому, что злоумышленник инициировал его че- 
рез поддельный запрос — он может быть легко прочитан кем-то из той же сети. Это похоже на 
перехват сеанса, описанный в главе 13. 


Доступны и другие параметры конфигурации, но перечисленные в табл. 15.2 исполь- 
зуются наиболее часто. Вместо того чтобы редактировать узел конфигурации <Ёогпз> 
вручную, можно воспользоваться инструментом конфигурирования аутентификации 
П$ 7. который напрямую работает с файлом иер .сопЁ19. Для этого откройте упомяну- 
тый инструмент, щелкните правой кнопкой мыли на компоненте Еогилз АитепйсаНоп 
и выберите в контекстном меню пункт ЕпаЫе (Включить). Затем еще раз щелкните пра- 
вой кнопкой мыши на Еогилз Аитепйсайоп и в контекстном меню пункт ЕОЙ (Изменить) 
для конфигурирования его настроек (рис. 15.3). 

Если компонент Югилз АнфеписаЯоп активизирован в файле иеь .сопЁ1<, то когда 
неаутентифицированный посетитель пытается обратиться к любому контроллеру или 
методу действия, помеченному атрибутом [АбЕпог12е| (или любому действию, возвра- 
щающему НЕЕрОпазеВог1хеаВези1+), он будет перенаправлен по ОВ! со страницей 
входа. 
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Рис. 15.3. Инструмент конфигурирования аутентификации 15$ 7 при редактировании парамет- 
ров Рогт$ Ампеписаноп 
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Обработка попыток входа 


Естественно, что для обработки запросов к ОЕ! со страницей входа понадобится до- 
бавить соответствующий контроллер, иначе посетители будут получать ошибку 404 М 
Рипа. Этот контроллер должен выполнять следующие функции. 


1. Выводить приглашение на вход. 

2. Принимать попытки входа. 

3. Проверять достоверность указанных регистрационных данных. 

4. Если регистрационные данные корректны, вызывать метод ЕохизАиВепе1 сало. 
зегАоЕБСоок1е (), который выдаст посетителю сооКе-набор аутентификации, по- 
сле чего переместить посетителя со страницы входа в другое место. 


5. Если регистрационные данные некорректны, повторно отобразить экран входа с 
соответствующим сообщением об ошибке. 


Вкачестве примера построения такогоконтроллера может послужить АссоипСопеко] Тег. 
по умолчанию включаемый в каждое создаваемое приложение АЗРМЕТ МУС, или упро- 
щенный вариант АссоспЕСопего!ТЛек, который рассматривается в примере приложе- 
ния ЗроцзЗ боге в главе 6. 

Обратите внимание, что контроллер АссочпЕСопеко11ехк из приложения Эро оге 
проверяет входные регистрационные данные, вызывая метод ГохизАцерепе1саЕ1оп. 
АцЕБепе1 сафе (), который ищет эти данные в узле <схейере1а1з> файла меб. соп#1с. 
Хранение регистрационных данных в иер.сопЁ19 иногда допускается для небольших 
приложений, в которых список аутентифицированных данных со временем не меняет- 
ся, но при этом следует помнить об ограничениях такого подхода. 


® Пароли в узле <сгедеп1а15> могут быть указаны в виде открытого текста, что 
сводит на нет все меры безопасности, если кто-то посторонний увидит этот файл. 
Даже когда пароли представлены в хептированном (с помощью алгоритмов МО5 
или ЗНА1) виде, нет возможности задавать начальное значения при хеширова- 
нии. Поэтому если злоумышленник прочитает содержимое файла иеЪ . сорЁ1 д, то 
он с высокой вероятностью сможет восстановить исходный пароль, воспользовав- 
шись приемом атаки с помощью радужной таблицы (гашЪом {аЫе)3. 


® Возникает проблема администрирования. Поддерживать в актуальном состоянии 
файл мер . сопЁ19 при наличии тысяч пользователей, меняющих пароли каждый 
день, очень непросто. Также следует иметь в виду, что при каждом изменении 
мер .сопЁ19 приложение сбрасывается, с очисткой кзша и хранилища сеансов. 


Чтобы преодолеть эти ограничения, не храните регистрационные данные в файле 
меь . сопЁ1 д и не применяйте метод ГогизАцеВепе1тсае той .АнцеВепе1саее () для про- 
верки попыток входа. Лучше либо реализовать собственное хранилище регистраци- 
онных записей, либо воспользоваться встроенным в АЗРМЕТ средством МепЪфегзЫр 
(Членство), которое рассматривается ниже. 


3 Радужные таблицы — это громадные базы данных, которые содержат предварительно вы- 
численные значения для огромного числа возможных паролей. Злоумышленник может бы- 
стро определить. содержится ли конкретное хеш-значение в таблице, и если да, то сразу 
получить соответствующий пароль. В Интернете свободно доступно множество таких ‘таб- 
лиц. Самый простой способ атаки на хеш-значения МОБ и ЗНА1. построенные без исполь- 
зования начального значения (5а1), предусматривает его ввод в строке поиска Соойе. Если 
в качестве пароля было выбрано слово из словаря, скорее всего, оно найдется довольно бы- 
стро. За счет добавления произвольного начального значения, которое даже не понадобится 
сохранять в тайне, хеш-коды можно сделать намного более устойчивыми к восстановлению. 
Злоумышленнику придется строить совершенно новую радужную таблицу с использовани- 
ем этого начального значения для всех хеш-кодов. А генерация радужных таблиц требует 
значительного времени и вычислительной мощности. 
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Применение Еогт$ АшмИеписаНоп 
в режиме без сооКе-наборов 


Компонент Еогтз АифепйсаНоп поддерживает редко применяемый режим без 
сооме-наборов (соок1@ез5), при котором билеты аутентификации сохраняются за счет 
включения их в ОВГ. До тех пор, пока каждая ссылка в рамках сайта содержит билет 
аутентификации посетителя, он остается в системе даже без поддержки соое-наборов 
в браузере. 

Почему поддержка соо е-наборов может быть отключена? Ведь в наши дни в подав- 
ляющем болыпинстве случаев она включена. К тому же известно, что многие веб-при- 
ложения просто не работают корректно, если не включить поддержку соое-наборов; 
например, болыпинство служб веб-почты просто сообщают посетителю о том, что тре- 
буют сооНе-наборов. Тем не менее, если конкретная ситуация требует этого, скажем, 
из-за того, что посетители используют старые мобильные устройства, в которых соове- 
наборы не разрешены, с помощью файла ие. сопЕ19 можно переключиться в режим 
без соое-наборов: 


<апчвепе1са1оп поде="Гогиз"> 
<Еогиз 1о091п0х1="-/Ассоипе/ТодОп" Е1теопф="2880" соок1е1езз="ОзеЦха" /> 
</Еогиз> 

</ааеБепЕ1са 1о1> 


После входа посетитель будет перенаправлен на ОВ! вроде такого: 


/ (Е (2м09017464АХхТ7 1 ОТТУОТТОЗЕСМТ О1ЕСУМАСаАККге-973олотокоУьхтхОЕИЕЗАЗач$ 
У0]0Уувр11НМ№М45ВЬ4 Е9СУсп Еп200х55Т3 Че51)) /Номе/5поиРг1уаеетиЕогиа1оп 


Внимательно присмотревшись, вы заметите, что этот ОВГ следует шаблону 
/ (Е (данныедутентификации) ) / обычный0ВГ. Здесь данные аутентификации заменяют 
(но не совпадают) те, что в противном случае сохранялись бы в сооНе-наборе .АЗРХАОТН. 
Естественно, это не соответствует конфигурации маршрутизации, но не беспокойтесь: 
платформа перезапишет входящие ОВГ, извлекая и удаляя данные аутентификации 
до того, как эти ОВЕ попадут в систему маршрутизации. Кроме того. до тех пор, пока 
исходящие ОБТ, будут генерироваться с использованием встроенных в МУС ЕгатехогК 
вспомогательных методов (вроде НЕп1.Асе1опЪ10К()), данные аутентификации будут 
автоматически добавляться в начало каждого генерируемого ОВ. Другими словами, 
это просто работает и все. 


Совет. Используйте аутентификацию без сооКе-наборов только в случае крайней необходимости. 
Она является довольно неуклюжей (достаточно лишь взглянуть на зти ЦВЕ), хрупкой (если на 
сайте случайно окажется хоть одна ссылка, не имеющая данных аутентификации, посетитель 
окажется выброшенным из приложения) и небезопасной. Если кто-то поделится ссылкой на 
ваш сайт, взяв УВЕ из поля адреса браузера, то любой, кто пройдет по этой ссылке, помимо 
воли позаимствует идентичность первоначального посетителя. Вдобавок, если на сайте выво- 
дятся изображения, расположенные на других сайтах, ваши предположительно секретные ЦВЕ 
будут отправлены им в заголовке Вегегег браузера. 


Членство, роли и профили 


Еще одним замечательным соглашением, принятым в Интернете. являются учетные 
записи пользователей. Что бы мы делали без них? Ведь с ними связано все самое важ- 
ное; регистрация, изменение паролей, установка персональных предпочтений итп. 
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Стандартная инфраструктура учетных записей пользователей входила в состав 
АЗР.МЕТ еще со времен версии 2.0. Она задумана и реализована как гибкая система: 
в нее входит набор АР-интерфейсов, описывающих инфраструктуру, а также ряд уни- 
версальных реализаций зтих интерфейсов. Фрагменты стандартных реализаций можно 
смептивать с собственными, соблюдая совместимость общими АР!-интерфейсом. Этот 
АР!-интерфейс состоит из трех основных частей. 


® Членство (Метфет$1Н р). Все, что касается регистрации пользовательских учетных 
записей и доступа к репозиторию детальной информации об этих записях и реги- 
страционных данных. 


® Роли (Кое$). Все, что касается назначения пользователей в набор (возможно пере- 
крывающихся) групп, которые обычно используются для авторизации. 


® Профили (РгоЩез). Позволяют хранить произвольную информацию для каждого 
пользователя отдельно (например, персональные параметры). 


Реализация определенного фрагмента АР-интерфейса называется поставщиком 
(рго\1аег). Каждый поставщик отвечает за собственное хранилище данных. АЗРМЕТ 
поставляется с набором стандартных поставщиков, хранящих данные в определенной 
схеме данных ЗОГ. Зегуег, в АсНуе Опесюгу и тд. Можно также создать собственный 
поставщик данных, унаследовав новый класс от подходящего абстрактного базового 
класса. 

Вдобавок ко всему этому АЗРМЕТ предлагает набор стандартных серверных элемен- 
тов управления \еЬЕоги1$, использующих стандартные АР!-интерфейсы для построе- 
ния пользовательских интерфейсов, ориентированных на решение распространенных 
задач, к которым относится и регистрация пользователей. Эти элементы полагаются 
на обратные отправки, поэтому они не слишком удобны для приложений МУС, однако 
довольно легко можно создать собственные элементы, в чем вы вскоре убедитесь. 

Описанная выше архитектура показана на рис. 15.4. 


Элементы управления \МеБЕоти$ . р 
для интерфейсов входа и членства Специальный пользовательский 


ых. ] Е И интерфейс для входа и членства 
Нельзя использовать в приложениях МУС (1. 2^\\ 


Приложение 


'АР|-интерфейсы членства; ролей и профилей 


Встроенный поставщик $01. Поставщик АсНуе Онесогу Специальный поставщик 
: . р постоянного хранения 
Удобен для небольших припожений Для корпоративных доменов. (дополнительный) 


Рис. 15.4. Архитектура членства, ролей и профилей 
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Ниже перечислены преимущества использования встроенной системы членства, ро- 
лей и профилей. 


В Мсгозой уже прошли весь процесс исследований и проектирования, чтобы, в ко- 
нечном счете, получить систему, которая хорошо работает в большинстве случа- 
ев. Это касается даже ситуаций, когда вы просто пользуетесь АР!-интерфейсами, 
но имеете собственное хранилище и пользовательский интерфейс. 

Для некоторых простых приложений встроенные поставщики постоянного хра- 
нения позволяют избежать необходимости в управлении собственным доступом к 
данным. Имея ясную абстракцию, обеспечиваемую АР!-интерфейсом, в будущем 
можно перейти на любой другой специальный поставщик, не изменяя код поль- 
зовательского интерфейса. 

АРГ-интерфейс разделяется всеми приложениями АЗРМЕЛ; что позволяет повтор- 
но использовать любые специальные поставщики или компоненты пользователь- 
ского интерфейса во множестве проектов. 

Система членства, ролей и профилей хорошо интегрируется с платформой 
АЗРМЕТ. Например, метод Озег.тзТпВо1е () является основой многих систем ав- 
торизации; он получает данные о ролях от выбранного поставщика ролей. 

При разработке некоторых неболыших приложений для корпоративной сети мож- 
но использовать встроенные инструменты администрирования АЗРМЕТ, такие 
как У\еЬ АапиулегаНоп Тоо! или средства конфигурирования членства, ролей и 
профилей ПЗ 7, для управления данными о пользователях без необходимости соз- 
дания собственного пользовательского интерфейса. 


Разумеется, встроенной системе членства, ролей и профилей присущи и некоторые 
недостатки. 


Встроенный поставщик хранилища ЗОГ, должен иметь прямой доступ к базе дан- 
ных, что не укладывается в строгие концепции модели предметной области. 
Встроенный поставщик хранилища ЗОГ, требует специфической схемы данных, 
которую нелегко совместно использовать со схемой данных остального прило- 
жения. $91РгоЁ11еРго\у1 Чек использует особенно своеобразную схему данных, 
в которой элементы профиля сохраняются в виде разделенных двоеточиями пар 
“имя/значение”, поэтому обычно их невозможно извлекать с помощью запросов. 
Как упоминалось ранее, встроенные серверные элементы управления непригод- 
ны для приложения МУС, так что придется разрабатывать собственный пользо- 
вательский интерфейс. 

Несмотря на то что инструмент \еЬ Аатиигайоп Тоо! можно применять для 
управления данными о пользователях, он не предназначен для развертывания 
на рабочем веб-сервере, и даже если сделать это. он будет выглядеть совершенно 
иначе, чем остальная часть приложения. 


В общем случае имеет смысл следовать АРГ-интерфейсу, ввиду его четкого разде- 
ления ответственности, возможности многократного использования в проектах и ин- 
теграции с платформой АЗР.МЕТ, а встроенный поставщик хранилищ ЗСТ. применять 
лишь для небольших или разовых проектов. 


Установка поставщика членства 


Платформа АЗР.МЕТ поставляется с поставщиками членства для ЗОТ, Зегуег 
(391МетъегзЬ1рРгкоу1 Чет) и Асвуе Пигесогу (Асе1уер1кесфогуМетъег=1рРгоу1 ег). 
Кроме того, можно загрузить образец поставщика Ассезз (БЕЕр://мзап.п1скозо#е. 
соп/ги-ки/аа336522.азрх) или создать собственный. Первые два поставщика исполь- 
зуются чаще всего, поэтому в данной главе речь пойдет в основном о них. 


Глава 15. Компоненты платформы АЗРМЕТ 501 


Настройка поставщика $31МетЬехгзЬ1рРгоу1Аег 


Вновь созданное приложение АЗРМЕТ МУС по умолчанию сконфигурировано на ис- 
пользование поставщика 591МепьегзВ1юРгоу19дег. В файле мер. сопЕла обычно при- 
сутствуют следующие элементы: 


<сопЕ1дигаЕ1от> 
<соппесЕ1оп5Е:119$> 
<ааа паме="Арр11са®1опбегу1сез" 
соппесЕ1оп5 Ек1ач="Чафа зоиксе=. \ЗОТЕХРВЕ$$ ;ТпбедкавеЯ Зесик1®у=$5РТт; 
АеЕасьовВЕ11епапе= |Рафар1гес®оху | азрпе ЧЪ .паЕ; 
Озек Тазбапсе=егае" 
Ргоу1ЧехМате="бузфем.Рафа.$491С11епе" /> 
</соппесЕ1о0п$%:1195> 
<5узЕет.иеб> 
<пешрегзВ1р> 
<ргоу1аегз> 
<с1еак/> 
<ааа паме="АзрМее5а1МеньегВ1рРго\14ек" 
фуре="Зузем.ИМеь .5есиг16у .591МетЬегзВ1рРго\у1Чег, ...“ 
соппесЕ1оп Ег1паМаме="Арр11са&1оп$егу1сез" 


... /> 

</ргоу1Аетз> 
</тетрегзВ1р> 
</зузЕев.меб> 
</сорЁ1сакаЕтоп> 


Работа с пользовательским экземпляром базы данных ЭОЕ Зегуег Ехргез$ 


Выпуски $ОГ. Эегуег 2005 Ехргезз Е@ ол и ЗСТ. Эегуег 2008 Ехргезз ЕФНоп под- 
держивают пользовательские экземпляры (изег ш$фапсе) базы данных. В отличие от 
обычных баз данных ЗСТ, Зегуег, эти базы не должны создаваться и регистрироваться 
заранее. Достаточно просто открыть соединение с ЗОГ. Зегуег Ехрге$$, указав местопо- 
ложение на диске файла МОЕ базы данных, и ЭОГ. Эегусг Ехргезз откроет этот файл, 
если тот существует, или создаст новый файл, если нет. Это удобно в простых сценариях 
веб-хостинга, потому что при этом даже не потребуется, например, конфигурировать 
данные для входа или пользователей. 

Обратите внимание, как это настраивается в приведенном выше файле меЬ . сопЕ1ч. 
В строке соединения по умолчанию указано Озег Тпзфапсе=егое. Специальный синтак- 
сис АЕЕасйОВЕ11епаше сообщает системе о необходимости создания пользовательского 
экземпляра базы данных ОГ, Зегуег Ехргез$ в -/Арр_Рата/азрпееа.маЕ. При перво- 
начальном создании базы данных АЗРМЕТ заполняет ее всеми таблицами и хранимыми 
процедурами, необходимыми для поддержки системы членства, ролей и профилей. 

Если данные планируется хранить на сервере ЭСТ. Зегуег Ехрге$$, то можно оставить 
эти настройки без изменений. Однако если в будущем должны использоваться выпуски 
ЗОТ, Зегусег, отличные от Ехрге$$. понадобится создать собственную базу данных и под- 
готовить ее схему вручную, как будет объясняться ниже. 


На заметку! Показанные выше настройки по умолчанию предполагают наличие локально уста- 
новленного выпуска ЗОЁ Зегиег Ехргез$. В противном случае любая попытка использования 
за1МеньегзВ1рРго\1 Чек приведет к ошибке с сообщением “ЗОЕЕхрге$$ дааразе Ше ащо- 
стеафоп етог” (Ошибка автоматического создания файла базы данных ЗОЁЕхрге$$). Потребуется 
либо установить ЗОЁ Зегиег Ехрге$$ локально, либо изменить строку соединения, чтобы она ука- 
зывала на другой сервер с ЗОЁ Зегуег Ехрге$$ или на базу данных, подготовленную вручную. 
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Подготовка собственной базы данных для поддержки 
системы членства, ролей и профилей 


Если необходимо использовать выпуск ЗОГ, Зегуег, отличный от Ехргез$ (например. 
любую его коммерческую версию), потребуется самостоятельно создать собственную 
базу данных обычным образом, те. с помощью ЗОТ, Зегуег Мапавбетеле Зеааю или \Узиа1 
Зелаю 2008. Чтобы добавить элементы схемы, нужные для 5$91Мепехт11рРго\у1 дек, 
запустите инструмент \И1пдомз\М1сгозоЕЕ.МЕТ\Егатемогк\и2.0.50727\азрпее _ 
те9591 .ехе без аргументов командной строки. Появится начальный экран мастера на- 
стройки АЗРМЕТ ЭОГ, Зегуег Зеёар УЙгага, показанный на рис. 15.5. 


2} АЗРМЕТ БО Зегиег Зезир М 


РЕЗО Сегьег ГЕТЕ. СЕЕЕЕЗЕ ВАТ 12 пеа ог ГЕССЕ, ее Ре слеасНЫЙЬ о све аеас 
380873 © ве 


Рис. 15.5. Инициализация собственной схемы базы данных для 
поставщика $491Менрехт1рРгоу1дек 


После указания местонахождения базы данных мастер добавит набор таблиц и хра- 
нимых процедур. которые необходимы для поддержки средств членства, ролей и профи- 
лей; все они имеют префикс азрпее_ (рис. 15.6). Затем следует отредактировать строку 
соединения в мер .сопЕ1а, чтобы она указывала на созданную вручную базу данных. 
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Рис. 15.6. Таблицы и хранимые процедуры, добавленные для поддержки поставщиков 
391 Метоегзр1рРго\у19ег, 541Во1ерто\у1аех и $91РкоЕ11еРгоу1 ег 
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Управление членством с использованием ИеБ Адтит$кгаНоп Тод! 


В составе \У!5ца! Эвлю имеется инструмент для веб-администрирования под назва- 
нием \еЬ Аатнизеанол Тоо! (МАТ). Это средство с графическим интерфейсом позво- 
ляет управлять настройками сайта, включая данными о членстве, ролях и профилях. 
Для его запуска из \1з0а1 Эва 10 выберите пункт меню Рго]ес{=>А$ЗР.МЕТ Сопйдигайоп 
(Проект=>Конфигурация АЗРМЕТ). На вкладке Зесигйу (Безопасность), показанной на 
рис. 15.7, можно создавать, редактировать, удалять и просматривать зарегистрирован- 
ные члены. 
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Рис. 15.7. Инструмент \М/АТ 


Внутри для взаимодействия со стандартным поставщиком членства инструмент 
У/АТ использует встроенные АР!-интерфейсы, так что он совместим с любым поставщи- 
ком МепрегзВ1рРгоу1дег, включая специально созданные. 

После развертывания в конечном итоге приложения на рабочем веб-сервере вы 
обнаружите, что инструмент У/АТ там недоступен. Причина в том, что УАТ являет- 
ся частью \15310а1 Эвл1ю — среды, которая вряд ли будет устанавливаться на веб-сер- 
вере. Теоретически развернуть У\/АТ на веб-сервере можно (см. Еогомз .азр.пеЕ/р/ 
1010863/1761029. азрх), но это довольно непросто, так что в действительности более 
вероятно, что для управления членством будет разработан собственный пользователь- 
ский интерфейс с использованием соответствующего АРГ-интерфейса. В случае сервера 
1$ 7 можно применять его инструмент конфигурирования МЕТ Озегз. 


Управление членством с использованием 
инструмента конфигурирования „МЕТ Цзег$ 


Среди множества разноцветных значков в диспетчере служб П$ 7 можно обнару- 
жить и значок „МЕТ Озегз (рис. 15.8). 
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Рис. 15.8. Графический интерфейс .МЕТ Озег$ в 1$ 7 


Наряду с созданием, редактированием и удалением членов. этот инструмент также 
позволяет конфигурировать поставитик членства по умолчанию. Подобно У/АТ, он редак- 
тирует корневой файл меб .сорЁ1а приложения и использует АРГ-интерфейс членства 
для взаимодействия с зарегистрированным поставщиком МетъегзВ1рРгоу1дег. 

В отличие от МАТ, инструмент .МЕТ Озегз будет доступен и на рабочем сервере (если 
на нем выполняется П$ 7). Оно предлагает базовую функциональность управления член- 
ством для неболыших приложений. где это делается только администратором сайта. 


Использование поставщика членства 
и компонента Гогт$ АИепнсаноп 


Скорее всего, возникнет необходимость использовать поставщик членства для 
проверки попыток входа. Это очень легко! Например, чтобы заставить приложение 
Эройз$оге работать с поставщиком членства, достаточно изменить одну строку кода в 
методе ГодОп (} класса АссоипеСопегко1Тек, как показано ниже: 


[АссерЕУетьз (НЕЕрУегьз .Роз$) ] 
ру611с АсЕ1опВези1 ТодОп ($61119 паше, зЕх1иа раззмога, зЕг1па гебигпог1) 
{ 
+Е (МешьегзЬ1р .Уа11Чафе0зег (паше, раззмога)) { 
// Назначить место перенаправления по умолчанию, 
// если оно не установлено 
тебоакпОг1 = гебагпОу1 ?? 0х1.АсЕ1оп ("Траех", "Ааплп"); 


// Установить соок1е-набор и выполнить перенаправление 
ЕогизАцЕВепЕ1сае1оп . ЗееАиЕВСооК1е (паме, Еа1зе); 
геогр Вед1ткесе (хебигпОг1}; ; 


} 


е1зе { 
Утемрафа ["1азЕТоб1пРа11е"] = &хие; 
тееако У1ем(}; 


} 


Ранее этот метод проверял попытки входа, вызывая метод ЕохмзАнеВепЕ1саЕ1 ор. 
АпЕрепетсате (папе, раззиого) , который ищет регистрационные данныевузле <скедепе1а1> 
файла меь - сопЕ19. Однако теперь он будет принимать попытки входа только с действи- 
тельными регистрационными данными, известными поставщику членства. 
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Создание специального поставщика членства 


Во многих случаях может оказаться, что встроенные в АЗРМЕТ поставщики член- 
ства не подходят для приложения. Поставщик Асе1уер1тесеогуМетретзВ1рРгоу1аег 
применим только в определенных сценариях с корпоративным доменом, а 
за1МепЪегзВ1юРгоу1 ег использует собственную специальную базу данных ЗОТ, ко- 
торую иногда нежелательно смешивать с существующей схемой. 

В такой ситуации имеет смысл создать собственный поставщик службы членства. 
унаследовав новый класс от МепъегзИ1рРго\у1аег. Начните с написания заголовка: 


риь11с с1азз МуМмемМепьетзЬ1рРтоу1Чег : МепьегзЬ1рРто\у1аег 
{ 
} 


Затем щелкните правой кнопкой мыши на МепьегзВ1рРгоу19дег и выберите в кон- 
текстном меню пункт итретег{ АБзгас! С1а$$ (Реализовать абстрактный класс). В этом 
классе имеется довольно много методов и свойств, которые в первоначальном виде ге- 
нерируют исключение МоЕТир1ецепеедЕхсеретов, но большинство из них можно ос- 
тавить без изменений. Для интеграции с компонентом Компз Аи епйсаНол в действи- 
тельности понадобится только метод Уа11дате0зет ()}. Ниже приведен очень простой 
пример реализации поставщика членства. 


риЬ11с с1аз$ 51ЕеМепрек 
{ 
руБ11с зЕг1пд ОзегМаше { деб; зе®; } 
риб11с зЕт1па Раззмога { дее; зе; } 
} 


раБ11с сТазз 51ир1еМептьетзВ1рРгоу1Аег : МепЪегзЬарРгоу1аег 
{ 
// Для простоты поставщик работает со статической коллекцией в памяти. 
// В реальном приложении регистрационную информацию потребуется 
// извлекать из базы данных. 
ргелуаЕе зЕаЕ1с Т1зЕ<51ЕеМепьег> МешЬегз = пем 1136<51ЕеМепрег> { 
пем 51ЕеМепрег { ОзехМаще = "Му0зехк", Раззиога = "МуРазз" } 
}; 


роБ11с охегт1ае Боо1 Уа11ЧаЕе0зег (3Ех1п9 изегпаще, зЕт1па раззиога) 
{ 
геЕагп Мепьетг$.Ех15{3 (п => (ш.ОзегМапе==изегпаие) & 5 (ш.Раззмога==раззмога)); 
} 
/* Опущено: остальные метоцы просто генерируют исключение №ЮПир1епепеедЕхсере1о>” 


} 
После создания зарегистрируйте собственный поставщик членства в файле "с. сопЁ19: 


<сопЕ1дигаЕ1о0т> 
<зузЕет.меь> 
<петрегзЬ1р Ч4еач1ЕРкгоузЯех="МуМепьегВ1рРгкоу1Чег"> 
<ргоу1аегз> 
<с1еак/> 
<ааЯ паме="МуметьегВ1рРгоу1 Дек" 
$уре="Мамезрасе .51тр1еМеиегзВ1рРгко\1 ег" /> 
</ргоу19егз> 
</петьегзВ1р> 
</зузЕет.меб> 
</сопЕ1дакаЕ1оп> 
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Если специальный поставщик членства должен поддерживать добавление и удаление 
членов и интегрироваться с инструментами АТ и .МЕТ Озегз для ПЗ 7, понадобится до- 
бавить переопределения других методов, таких как Сгеате0зег() и беёА1105егз (). 


Внимание! Несмотря на легкость создания собственного поставщика членства и применения его 
в приложении, заставить его взаимодействовать с инструментом .МЕТ Цзегз сервера 11$ 7.5 не- 
сколько сложнее. На момент написания книги, зтого можно было добиться лишь за счет поме- 
щения поставщика в строго именованную сборку .МЕТ, регистрации этой сборки в САС сервера 
и ссылки на нее в файле Ади1п1 зе ха 1 оп. сопЕ1а на сервере. 


Настройка и использование ролей 


До сих пор было показано, как платформа управляет набором регистрационных 
данных, проверяет попытки входа (с помощью поставщика членства) и отслеживает со- 
стояние зарегистрированных пользователей между множеством запросов (посредством 
компонента Еогиз$ АипептйсаНон). Все это касается аутентификации, т.е. безопасной 
идентификации конкретного лица. 

Следующим распространенным требованием безопасности является авторизация, 
означающая принятие решений относительно того, что разрешено делать определен- 
ному лицу. Платформа предлагает систему авторизации на основе ролей, посредством 
которой каждому пользователю может быть назначено множество ролей, и его членст- 
во в каждой роли подразумевает разрешение на выполнение определенных действий. 
Роль — это просто уникальная строка, которая имеет смысл в том плане, который ассо- 
циируется с этими строками. Например, можно выбрать следующие три роли: 


® АрргоуедМепрех 
® Соппепе$Модегаеогк 


е З1теАЧило1зегкаеок 


Это просто произвольные строки, которые приобретают смысл, когда, напри- 
мер, приложение предоставляет консоли администратора доступ только членам роли 
51ЕеАдт1 01 зе гафог. Каждая роль совершенно независима от остальных — здесь нет 
иерархии, поэтому принадлежность к роли 5$16еАдп1015Егафог не означает автомати- 
ческой принадлежности к роли СоппепЕМодегафсог или даже АрргоуеЯМепрег. Каждая 
роль может быть назначена независимо, и каждый член может иметь любую комбина- 
цию ролей. 

Как и с членством, платформа АЗР.МЕТ ожидает, что работа с ролями будет прово- 
диться через модель поставщиков с использованием общего АР! -интерфейса (базового 
класса Во1еРгоу1ает) и набора встроенных поставщиков. И, конечно же, можно реали- 
зовать собственный специальный поставщик. 

Как и в случае членства, управлять ролями (назначать и отбирать роли у членов} 
можно с помощью У/АТ или инструментов конфигурирования МЕТ Кез и .МЕТ Озег® 
сервера П$ 7, как показано на рис. 15.9. 

Во многих случаях намного удобнее не пользоваться встроенными инструментами, а 
создавать собственные специальные экраны администрирования внутри приложения. 
Для управления ролями служит статический объект Зузеет.Меь . 5есиг1®у.Ко1ез, ко- 
торый предоставляет поставщик членства по умолчанию. Ниже показан пример добав- 
ления пользователя к роли: 


Во1ез .АЯЯ0зегТово1е ("Б1119", "СоппепЕзМодетатог"); 
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Рис. 15.9. Использование инструмента .МЕТ Цзег$ из И$ 7 для редактирования ролей 
пользователя 


Использование встроенного поставщика $41Ко1ерРгоу1Аег 


Если вы пользуетесь поставщиком 591МептрегзВ1рРго\у14етх, то обнаружите, что 
вместе с ним удобно применять поставщик 591Ко1еРгоу1аег, получая в результате 
удобный и быстрый способ добавления в приложение авторизации на основе ролей“. 
Файл ме. сопЕ1а в новом приложении АЗРМЕТ МУС содержит следующие настройки: 


<сопЕ1дагаЕ1отп> 
<зузфет.иеБб> 
<го1еМападег епаЪ1ед="#а1зе"> 
<ргоу14ег5> 
<с1еак/> 
<ааа пате=“АзрМее$а1Ко1еРргоуз ег" 
фуре="Зузвем.Меь. $есиг1 у .5а1Ко1еРргоул4ек, ..." 
соппесЕ1оп5 Ег1паМаме="Арр11са1оп$егу1сез" 
арр1зсаезопМате="/" /> 
<ааа паме="АзрМееИапаонзТоКкепВо1еРко\1 ет" 
фуре="Зузвем.Меь .5есик1 у .И1паонзТокепро1еРгоу1Аек, ...“ 
арр11са1лопМаме="/" /> 
</ргоу1дек=> 
</хо1=Мападег> 
</зузеет.иеь> 
</сопЕ1дахаЕ1от> 


Как видите, в файле перечислены два возможных поставщика ролей, но ни один из 
них по умолчанию не активизирован. Чтобы включить 5а1Во1ергоу19ег, измените ат- 
рибуты узла <го1еМападег> следующим образом: 


<го1еМападег епаЪ1ед="Е кие" ЧеЕао1ЕРгоу1Вег="АзрМее$а1Во1еРгоулдек"> 


Предполагая, что схема базы данных уже создана, как было описано для 
3а1МеньегзВ1рРгоу19ек, поставщик ролей теперь готов к работе. В качестве альтер- 
нативы можно назначить АзрМ№еИ1паоизТокепВо1еРгоу19дег поставщиком службы 
ролей по умолчанию, если применяется компонент УЯпао\з АиепНсаНол и нужно. 
чтобы роли пользователей определялись их ролями в УЯпао\/з Аснуе Птесюгу. 


ы Даже если поставщик 5$91МепьекзВ1рРкоу1дех не используется, 591Во1ерРгоу1 ег формаль- 
но применять можно. Однако вряд ли это целесообразно: он основан на той же самой схеме 
базы данных, что и 5а1Меньегз1рРгоу19ек. 
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Защита контроллеров и действий с помощью ролей 


Ранее было показано, как использовать встроенный в АЗР.МЕТ МУС фильтр 
[АаЕНог12е] для ограничения доступа только аутентифицированным посетителям. ко- 
торым назначена определенная роль. Например: 


[АцЕВог1 те (Ко1ез="Соптеп® Модекаког, $15еАдт1и15Егаког") ] 
руБ11с У1емВези1Е АрргоуеСоттепе (1пЕ сошмепЕТтТа) { 
// Реализовать 


} 


Если указано несколько разделенных запятыми ролей, посетитель получает доступ, 
если принадлежит к любой из перечисленных ролей. Фильтр [АсеКог12те] более подроб- 
но описан в главе 9. Чтобы защитить весь контроллер, атрибут [АзЕНог1 те (во1ез=...)] 
следует назначить классу контроллера вместо индивидуального метода действия. 

Для более широкого программного доступа к информации о ролях метод дей- 
ствия может вызывать Озег.ТзТпВо1е (имяРоли), чтобы определить принадлеж- 
ность текущего посетителя к определенной роли, или Зузтет.Меь.Зесог1еу.Во1ез. 
СеЕВо1езРогОзег (). чтобы получить список всех ролей, которые были назначены те- 
кущему посетителю. 


Создание специального поставщика ролей 


Совершенно не удивительно, что для создания собственного поставщика ролей необ- 
ходимо унаследовать новый класс от базового класса Во1еРкго\1 дет. Как и ранее, мож- 
но воспользоваться пунктом третет Абзгас! С!а$$ (Реализовать абстрактный класс) 
контекстного меню в среде У\У15ща! ЭилА1о для получения определения типа без написа- 
ния реального кода. 

Если оперативное управление ролями не требуется (например, с помощью инстру- 
мента конфигурации .МЕТ Коез сервера П$ 7 или У/АТ), достаточно только добавить ре- 
альный код в метод бсееВо1езЕогОзег (). как показано ниже: 


руБ11с с1азз Муво1еРтоу1Ает : ВКо1еРгоу1ает 
{ 
руБ11с оуекк1Ае зЕт1па[] сееВо1езЕогОзек (зек1па изегпате) 
{ 
// реальный поставщик, скорее всего, будет извлекать информацию 
// о ролях из базы данных 


1Е (азегпаше == "5феуе") 
тебагп пеи зЕт1п9[] { "АрргоуедМетрек", "СоштептЕ$Модегаеог" }; 
е1зе 


тебиги пем з6г1лиа[] { }; 
} 
/* Опущено: остальные методы генерируют исключение М№оЕТир1етепеедЕхсере1от* / 


} 


Чтобы использовать этот специальный поставщик ролей, отредактируйте узел 
<го1еМападег> файла ме .сопЕ1ч, назначив этот класс в качестве поставщика ролей 
по умолчанию, или сконфигурируйте это с помощью диспетчера служб ПЗ 7. 


Настройка и использование профилей 


Членство позволяет отслеживать членов, а роли — разрешенные им действия. Но 
что, если необходимо хранить и отслеживать другие данные. индивидуальные для каж- 
дого пользователя, вроде особенностей членства, параметров сайта или любимых блюд? 
Здесь на помощь приходят профили — универсальное хранилище данных, специфиче- 
ских для каждого пользователя, которое следует знакомому механизму поставщиков. 
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Это привлекательный выбор для неболыпих приложений, которые построены на ос- 
нове поставшиков $91МептЪегз61рРто\у19ег и 591Ко1еРгоу1@ег, поскольку при этом 
используется та же самая схема базы данных. и создается впечатление, что вы получае- 
те нечто бесплатно. Однако в более крупных приложениях, когда имеется специальная 
схема базы данных и более строгое писание модели предметной области, скорее всего, 
предпочтение будет отдано другой, лучшей инфраструктуре для хранения данных каж- 
дого пользователя, так что выигрыша от использования ролей не будет никакого. 


Использование встроенного поставщика 5$а1РгоЕ11еРгоулаег 


Сразу после создания схемы базы данных для членства, ролей и профилей с помо- 
щью инструмента азрпеЕ_гед$41 .ехе (или позволив создать се автоматически, если 
используется ЗОТ, Зегуег Ехргезз Еаол с файловой базой данных) можно использовать 
встроенный поставщик профилей под названием 591Рто{11еРгоу1ает. По умолчанию 
он активизирован в каждом новом приложении АЗРМЕТ МУС, потому что меб .сопЕ19 
содержит следующее: 


<сопЕ1дагаЕ1о0от> 
<зузЕет.меБ> 
<ргоЕ11е> 
<ргоутаегз> 
<с1еаг/> 
<ааа паме="АзрМее$а1РгоЕ11еРгоу14ег" 
$уре=" бузкем.МеЪ.РкоЕ11е. 591РкоЕ141еркоу1аек, ..."“ 
соппесЕ1оп$ Ег1поМаме="Арр11сазоп$егузсез" 
арр1асаклопМате="/" /> 
</ргоу1Аегз> 
</ркоЕ11е> 
</зузсем.меб> 
</сопЕ1адагаЕ1оп> 


Конфигурирование, чтение и запись данных профиля 


Прежде чем можно будет читать и записывать данные профиля, необходимо опреде- 
лить структуру данных, с которой будет проводиться работа. Это делается добавлением 
узла <ргорекЕ1ез> в узле <ргоЕ11е> файла мер . сопЕ1фо. Например: 


<ргоЕ11е> 
<ргоу19етз>...</рхгоу14егз> 
<ргорег®лез> 
<аЯЯ папе="Маще" суре="$Екапа" /> 
<аЯ9Я пате="РозпеЗсогей" куре="Тифедех" /> 
<дхоир паие="АЗагез$"> 
<а9Я пате="ЗЕкеефк" куре="$%к4па" /> 
<а@& паме="Саеу" вуре="$Егаиа" /> 
<аЯа паше="74рСо4е" Еуре="5Ег4 па" /> 
<ааа паше="$$аее" суре="$ек1па" /> 
<аЯа пате="Соичпегу" Буре="5 ела" /> 
</ахочр> 
</ркорегЕ1е5> 
</ргоЕ11е> 


Как видите, свойства могут объединяться в группы, и для каждого свойства должен 
быть указан тин „МЕТ. Разрешается использовать любой тип .МЕТ при условии, что он 
поддается сериализации. 
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Внимание! Следует помнить, что использование любого тина кроме наиболее базовых (5Ех1па, 
1пЕ ит.) будет отрицательно сказываться на производительности, если только не реализу- 
ется собственный специальный поставщик профилей, которому нужны типы помимо базовых. 
Поскольку $41РтоЕ11еРго\у1дег не может обнаружить, модифицирован ли определенный 
специальный объект во время запроса, он записывает полный набор обновленной информации 
о профиле в базу данных при каждом запросе. 


Имея готовую конфигурацию, можно читать и записывать данные профилей каждо- 
го пользователя в методах действий: 


рчь11с АсЕ1опВези1е ЗвоиМепретМамеАпЯСоциеку () 

{ 
УтемРата ["шетьегМаше"] = НЕЕрСопЕехЕ -РхоЕ11е ["Мапе"]; 
УтемрВака ["тепъегСоипеку"] 


= НЕЕрСореехЕ .РхоЕ11е .СеЕРгоЕ11ескоир ("Адахезз") ["СоипЕгу"]; 
тебигп Утем(); 


} 


риБ11с Вед1тгесеТоВоцеевези1Е Зе МепреуМатеАп Сонику (зЕк1по папе, 5Ех1п9 соцпегу) 
{ 


НЕбрСопеехЕ.РгоЕ11е["Маше"] = папе; 


НЕЕрСоптехЕ .РхоЕ11е.СеЕРтоЕ1 1ебтопр ("Ааагезз") ["Социеку"] = соипегу; 
тефоагп Вед] хесеТоАсЕ1 оп ("бноиМепьегМамеАпаАСоипегу") ; 


} 


Платформа загружает данные профиля зарегистрированного пользователя при пер- 
вой попытке обращения к одному из сго значений и сохраняет все изменения в конце 
запроса. Явно сохранять изменения на понадобится — все происходит автоматически. 
Обратите внимание, что по умолчанию это работает только с зарегистрированными, 
аутентифицированными посетителями, а при попытке записать свойства профиля те- 
кущим неаутентифицированным посетителем генерируется исключение. 


Совет. Проектировщики зтого средства предполагали, что доступ к данным профиля будет осу- 
ществляться через строго типизированный прокси-класс, автоматически сгенерированный на 
основе конфигурации <ргорегЕ1тез> (например, РгоЕ11е.Адагезз. СоппЕку). К сожале- 
нию, этот прокси-класс генерируется автоматически только при использовании веб-проектов, 
а не веб-приложений в Миа! Зиаю. Приложения АЗРМЕТ МУС — это веб-приложения, а не 
веб-проекты, и потому для них такой прокси-класс генерироваться не будет. Если действитель- 
но необходим строго типизированный прокси-класс, обратитесь к проекту Меб РгоМе Вийдег 
(ВЕЕр://соде .шзЯп.иаскозоЕ+. сот/МерРгоЕ11еВи11 дет). 


Платформа также поддерживает понятие анонимных профилей, в которых дан- 
ные профиля, ассоциированного с незарегистрированными посетителями, могут со- 
храняться между сеансами браузера. Для активизации таких профилей сначала по- 


метьте одно или более определений свойств профиля в файле меь. сопЕ1а атрибутом 
а11о\Апопупоиз: 


<рхоЕ11е> 
<ргорегЕ1ез> 
<аЯа паме="Мащше" сБуре="5 капа" а11омАпопумонз="Егае" /> 
</ргореге1ез> 
</ргоЕ11е> 
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Затем включите анонимную идентификацию в мер .сопЕ19: 


<сопЕ1аикае1оп> 
<зузбепт.мер> 
<апопупоп5ТЯете1Е1са1оп епаб1ед=" гие" /> 
</зузеет.мер> 
</сопЕ1аагае1ой> 


Это значит, что АЗРМЕТ будет отслеживать посетителей, выдавая им сооНе-набор 
по имени .АЗРХАМОМУМОЙ$, который по умолчанию действителен в течение 10 000 ми- 
нут (менее 70 дней). В узле <апопупоизТаепе1Е1сас1оп> можно задавать множество 
настроек, в том числе имя соове-набора, срок его истечения и тн. 

Эта конфигурация позволяет читать и записывать свойства профилей для неаутен- 
тифицированных посетителей (в данном примере — только свойство Маше), но следует 
иметь в виду. что теперь для каждого неаутентифицированного посетителя будет пре- 
дусмотрена отдельная регистрационная запись в базе данных. 


Создание специального поставщика профилей 


Как это принято в модели поставщиков АЗРМЕТ, имеется возможность создания спе- 
циального поставщика службы профилей, наследуя его от абстрактного базового класса 
РгоЕ11еРго\1 дек. Если поддержка управления профилями с помощью УАТ или инст- 
румента конфигурации МЕТ Ргойез из П$ 7 не нужна, потребуется только добавить код 
в методы бееРкорегку\Уа10ез () и ЗееРгорегеу\Уа1аез (). 

В рассматриваемом ниже примере код не сохраняет состояния в базе данных и не 
является безопасным в отношении потоков, поэтому не вполне реалистичен. Однако он 
демонстрирует работу АР!-интерфейса РгоЁ11еРго\14ег и доступ к индивидуальным 
элементам данных профиля с целью загрузки и сохранения. 


руЮю11с сфазз ТиМетогуРго#11еРгоу1Аег : РгоЕ11еРгоу1Чег 
{ 
// Это находящаяся в памяти коллекция, которая никогда не сохраняется на диске. 
// Предупреждение: для краткости код не сделан безопасным в отношении потоков. 
// Ключами в словаре служат имена пользователей, а значениями - 
// словари данных профиля для конкретного пользователя. 
ре1уаке зкаф1с ТР1сЕ1опагу<з6г1па, ТО1сЕ1орагу<зег1поа, обдес®>> _Чаба 
= пеи О1сЕ1опагу<зЕг1тпд, ТРасе1опагу<зег1па, обдес®>> (); 


руЮ11с оуегг1 де бе &1позРгорегеу\а1аеСо11есЕ1от СееРгорегкуУа1 лез { 
Зеее1пазСорфехЕ сопсехе, Зесе1пазРгорекЕуСо11есе1оп со11ес®1оп) 


// Проверить, получена ли запись с данными профиля пользователя 
Трасетопагу<зег4па, оБ)есЕе> изеграфа; 
_Чафа.Ткубее\Уа1 че ( (56 х109) сопеех® ["Озе’Мате"], обе изеграка); 


// Теперь построить и вернуть коллекцию Зее 1пазРгорегеуУалеСо1есе1оп 
уаг гези1е = рем бесе1одзРкорегеуУааеСо1есЕтоп (); 
ЕогеасВ (5еёе1пазРкорегеу ргор 1п со11есе1оп} 
{ 

уаг зру = поем беселпазРгорегеуУа1е (ргор); 

1Е (пзеграба != по11) // Использовать данные профиля пользователя, 

// если они доступны 
зру.РгорегеуУа1ие = изегрРафа[ргор .Маше]; 

тези1е.АЧа (эру); 

} 


гесагп ге5о1%; 
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руЮ11с оуегг1@ае уо1а ЗееРгорегку\Уа1щез (Зее Е1п9зСопеехе сопфехе, 
ЗеЕЕ1п9зРгорекбуУа1леСо11ест1оп со11есе1оп) 


{ 


3Ег1пд9 изегМаше = (365119) соптехе ["ОзехМаше"]; 
ТЕ (36:19. 135М№11ОкЕтреу (изегМаше} ) 
тебиги; 


// Просто преобразует коллекцию бее1пазРгорегеуУа1аеСо1ТесЕ1оп в словарь 
_Я@аба [азегМапе] = со11есЕ1оп .Сазе<бесе1пазРгорегеуУа1ае> () 
.ТортсЕлопагу(х => х.Маше, х => х.РгорегсуУа ше); 
} 
/* Опущено: все остальные методы генерируют исключение № Итр]етепеедЕхсер 1оп*/ 


} 


В специальном поставщике можно игнорировать идею групп свойств и восприни- 
мать данные как коллекцию пар “ключ/значение”, потому что АР!-интерфейс работает 
в терминах полностью определенных разделенных точками имен свойств наподобие 
АЯ@гезз .Зегее+. Также не нужно беспокоиться об анонимных профилях — если они 
разрешены, то АЗРМЕТ будет генерировать СОТР-идентификатор в качестве имени для 
каждого анонимного пользователя. В коде не должны делаться различия между ними и 
реальными именами пользователей. 

Естественно, специальный поставщик профилей должен быть зарегистрирован в 
Узле <ргоЕ11е> файла мер . сопЁ1 сд. 


Авторизация на основе ЦВЕ. 


Традиционно АЗРМЕТ сильно зависит от соответствия ОВ, структуре папок исход- 
ного кода, так что имеет смысл определять правила авторизации в терминах шаблонов 
ОКУ. Так, например, в У\еБЕотиз весьма вероятно, что административные страницы 
АЗРХ будут размещены в папке по имени /АЧт1о/, поэтому с помощью авторизации на 
основе ОКТ, можно разрешить доступ к /Ади1о/* только зарегистрированным пользо- 
вателям, которым назначена некоторая специфическая роль. Кроме того, можно пре- 
дусмотреть специальное правило, чтобы пользователи, вьышпедшие из приложения, по- 
прежнему имели доступ к /Аат1т /Тод1т/азрх. 

Платформа АЗРМЕТ МУС поддерживает исключительно гибкую систему маршрути- 
зации, поэтому не всегда имеет смысл конфигурировать авторизацию в терминах шаб- 
лонов ОБЕ. Предпочтение может быть отдано более высокой точности, которую обеспе- 
чивает добавление атрибута [АиЕПог12е] к индивидуальным контроллерам и мегодам 
действий. С другой стороны, иногда имеет смысл принудительно навязать авторизацию 
в терминах шаблонов ОБТ, так как в соответствии с принятым соглашением админист- 
ративные ОКЕ всегда начинаются с /Адтаь/. 

Авторизация на основе ОНТ, устанавливается в приложении МУС с помощью У/АТГ 
или же непосредственным редактированием файла мер .сопЕ19. Например, поместите 
приведенные ниже строки непосредственно над (и вне) узла <зузЕем.меф>: 


<1ТосаЕ1оп рафп="Адизт"> 
<зузбем.иер> 
<апЕПог1хае1топ> 
<аепу пзегз="?"/> 
<а11ои го1ез="51ЕеАди1а"/> 
<Чепу изегз="*"/> 
</азЕБог1хаЕ1ов> 
</зузфет.меб> 
</1осаЕ1оп> 
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Это укажет модулю Ог1АиЕВог1 хас1опМодиа1е (который зарегистрирован для всех 
приложений АЗРМЕТ по умолчанию), что для ОКГ -/Адилт и ОБЕ, соответствующих 
гтаблону -/Ади1в/*, должны предприниматься следующие действия. 


® Запретить доступ для неаутентифицированных посетителей (<4епу изегз="?"/>). 


® Открыть доступ для аутентифицированных посетителей с ролью 51ЕеАдт1п 
(<а1фом го1ез="515еАат1ю"/>). 


® Запретить доступ ко всем прочим посетителям (<Чепу изегз="*"/>). 


Когда посетителям запрещен доступ, модуль Ог1АсеВог1хае1опМоЧиа1е устанавли- 
вает ответ НТТР 401, означающий “не авторизовано”, и вызывает активный механизм 
аутентификации. В случае использования компонента Еогтз Аи епйсаНоп это означа- 
ет, что посетитель будет перенаправлен на страницу входа (независимо от того, вошел 
ли он в систему). 


Внимание! Авторизация на основе ЦВЕ работает корректно, только если установлена версия 
„МЕТ Ратемогк 3.5 5Р1. Без пакета обновлений ЗР1 авторизация вызывается только для узлов 
<1осаЕ1оп>, атрибут раз которых соответствует действительному файлу или папке на диске. 


В большинстве случаев более логично определить правила авторизации на кон- 
троллерах и действиях, используя фильгры [АйеВог12е], чем на шаблонах ОВ в 
мер .сорЁ1д, потому что в таком случае схему ОБТ, можно изменять. не беспокоясь о 
возможных брешах в системе безопасности. 


Кэширование данных 


При наличии данных, которые должны сохраняться между несколькими запросами, 
их можно хранить в коллекции Арр11саЕ1оп. Например. метод действия может содер- 
жать следующую строку: 


НЕсрСопеехе.Арр11саетоп ["мудафа"] = зопеТпрогеап® Рафа; 


Объект зометирогЕапеРака останется активным в течение времени выполнения 
приложения и всегда будет доступен в НЕЕрСопеехе .Арр11саЕ1 оп ["мудаха"]. В ре- 
зульгате может показаться, что коллекцию Арр11сае1от можно применять в качестве 
кэша для объектов или данных, которые требуют затрат при генерировании. На самом 
деле, коллекцию Арр11са1оп можно использовать подобным образом, но тогда придет- 
ся самостоятельно управлять временем жизни кэптированных объектов. В противном 
случае коллекция Арр11саЕ1оп будет бесконтрольно расти в размерах, потребляя все 
болыпий объем памяти. 

Намного лучше воспользоваться встроенной в АЗР.МЕТ структурой данных Сасбе 
(Зузеем.Мер.СасЬ119 .СасВе). Она включает в себя готовые средства управления вре- 
менем хранения и памятью, и контроллеры могут легко получать доступ к ее экземпля- 
ру через НебрСопеехЕ .СасВе. Эту структуру пелесообразно применять для хранения 
результатов любых дорогостоящих вычислений или извлечений данных, таких как об- 
ращения к внешним веб-службам. 


На заметку! НЕЕрСопеехе .Сасфе выполняет кэширование данных, что существенно отличается от 
кэширования вывода. Кзширование вывода фиксирует НТМЕ-ответ, посланный методом действия. 
и затем повторяет его для последующих запросов того же самого ЦВЕ, сокращая количество за- 
пусков метода действия. Дополнительные сведения о кэшировании вывода можно найти в разделе 
“Фильтр действия [ОцЕриЕСасВе]” главы 9. С другой стороны, кзширование данных позволяет 
гибко кзшировать и извлекать произвольные объекты и использовать их по своему усмотрению. 
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Чтение и запись данных в кэш 


Структуру СасБе проще всего применять в качестве словаря имен и значений, при- 
сваивая и извлекая значение из НЕерСопеехе .СасВе [Кеу]. Данные сохраняются и 
совместно используются всеми запросами, автоматически удаляясь из памяти по дос- 
тижении некоторых пороговых значений использования памяти или по истечении неко- 
торого достаточно долгого периода, в течение которого данные не были востребованы. 

В структуру Саспе можно помещать любой объект .МЕТ который даже не обязательно 
должен быть сериализуемым, поскольку платформа хранит его в памяти как действую- 
щий объект. Элементы структуры СасВе не обрабатываются сборщиком мусора, так как 
в них содержатся только ссылки на такие объекты. Конечно, это также означает что весь 
граф объектов, достижимый из кэтированного объекта, не может быть удален в процессе 
сборки мусора, поэтому будьте осторожны и не кэшируйте больше, чем необходимо. 

Вместо простого присваивания значения НеЕрСопеехь. Сасве [Кеу] лучше пользо- 
ваться методом НЕЕрСопеехе .Сасйе. Аа (), который позволяет конфигурировать пара- 
метры хранения, перечисленные в табл. 15.3. 


Таблица 15.3. Параметры, которые можно указывать при вызове 
НЕЕрСопеехе.СасНе.Ада () 
ООВ 


Параметр Тип Описание 


Черепдепс1ез СасБеререпаепсу Позволяет указать одно или более имен фай- 
лов либо ключей других элементов кзша, от 
которых зависит данный элемент. Когда лю- 
бой из этих файлов или элементов кэша изме- 
нится, данный элемент будет удален из кэша. 


абзотиееЕхрага 1оп  Рабеташе Это фиксированный момент времени, ко- 
гда злемент будет удален из кэша, Обычно 
указывается относительно текущего 
времени (например, РасеТате . Мом. 
АЗОНочгз (1) ). Если интересует только 
абсолютная дата устаревания, установите 
$1191 п9Ехр1гае1 ол в Типебрап. 7его. 


31101 п9Ехр1га1оп  Тиебрав Если к элементу кзша не было обращений 
(те. он не извлекался из коллекции каша) в 
течение как минимум указанного периода 
времени, этот элемент удаляется из кэша. 
Создавать объекты Т1пебрап можно с по- 
МОЩЬЮ методов Т1тебрап .ЕгошххХ () (на- 
пример, Т1тебрап . ЕгощМ1 пафез (10) ). 
Если вы заинтересованы только в отно- 
сительном сроке действия, установите 
арзо1аееЕхр1 га®1оп в РасеТ1ше. 
МахУа1 ще. 


ре1ог1еу СасвеТкетРт1ог1еу Если система удаляет элементы из кэша по 
причине нехватки памяти, первыми будут 
удалены элементы с меньшим приоритетом. 


опКешоуеСа1раск СаспетЕешВеноуеЯСа11Ъаск Позволяет указать функцию обратного вызова 


для получения уведомлений об устаревании 
элемента. Ниже будет приведен пример. 
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Как упоминалось ранее, структура Сасве часто используется для кэширования ре- 
зультатов вызовов дорогостоящих методов, таких как определенные запросы базы дан- 
ных или обращения к веб-службам. Недостаток состоит в том, что кэшированные дан- 
ные могут устареть и не отражать актуальные результаты. Поэтому при решении того, 
что нужно кэшировать и на какое время, приходится идти на компромиссы. 

Например, предположим, что веб-приложение выполняет НТТР-запросы к другим веб- 
серверам. Это может понадобиться для обращения к веб-службе ВЕЗТ, для извлечения 
содержимого КЗ$-каналов или для выяснения, какой логотип Сообе отображает на теку- 
щий момент. Каждый такой НТТР-запрос к стороннему серверу может занять несколько 
секунд, в течение которых посетителю сайта придется ожидать ответа. Поскольку эта. 
операция является дорогостоящей, имеет смысл кэшировать ее результаты. 

Описанную логику можно инкапсулировать в классе по имени сасфед\еюВесаезе5ету1се. 
реализованном следующим образом: 


рор11с сфазз Сасфед\ерюВедиезе5егу1се 
{ 
рг1уасе Сасбе сасфе; // Причина хранения этого станет ясной позже 
ре1уафке сопзЕ зех1пд саспекеуРгеЁ1х = "__саспед\еювесиез5егу1се"; 
раЮ11с Сасцед\МерведаезЕбету1се (Саспе сасВе) 
{ 
{Ъ15.сасБе = сасве; 


} 


рур11с зЕг1па СбеемерюРаде (зЕт1па итт) 
{ 
зЕг1па Кеу = састекКеуРге{1х + иг1; // Вычислить ключ кэща 
зЕг1п9 БыйЬ = (36.119) сасре[кеу]; // Попытаться извлечь значение 
ТЕ (Ре == по11) // Проверить, присутствует ли оно в кзще 
{ 
// Реконструировать значение, выполняя действительный НТТР-запрос 
Бе = пем ИерС11епе () .Роип1оа@а5Ет1па (пут); 
// Кэшировать результат НТТР-запроса 
сасВе.Тпзег® (Кеу, Вет, по11Ъ, РабеТ1ме.МахУа1ае, 
Т1пебрап .ЕгомМтпаеез (15), СаскеТеетРу1ог1еу.Могиа1, по11}; 
} 
тееако 661; // Вернуть извлеченное или реконструированное значение 
} 
} 


К экземпляру этого класса можно обратиться в методе действия, передав его конст- 
руктору в качестве параметра коллекцию НЕЕрСопеехе .СасВе: 
рир11с зЕг1лпа Тпаех () 
{ 
уаг смгз = пем Сасцед\еювесаез{$егу1се (НЕЕрСопеехе.Саспе); 
зЕг1па БЕбрВезропзе = сигз .СееМеюРаде ("Веер : / /мим.ехатшр1е.сой"); 
тебикгп зег1лпа.Еогтаф ("ТЬе ехапшрЪе.сош ропераде 1$ {0} свагасеегз 1опа.", 


БеЕрвезропзе.ТепаеН) ; 
} 


Здесь необходимо отметить два момента. 


ы Каждый раз, когда этот код извлекает элементы из коллекции СасВе, он проверя- 


ет, не равно ли пи11 извлеченное значение. Это важно, потому что элементы мо- 
гут быть удалены из Сасне в любой момент, даже до истечения заданного времени 
хранения. Ниже описана типичная последовательность действий для получения 
значений (как было показано в предшествующем примере). 
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1. Вычислить ключ кзша. 
2. Попытаться извлечь значение по этому ключу. 


3. Если в результате получено по11, реконструировать значение и добавить его в 
кэш под этим ключом. 


4. Вернуть значение, которое было извлечено или реконструировано. 


Если несколько компонентов приложения совместно используют одну и ту же 
коллекцию СасВе (обычно в приложении имеется только один экземпляр СасНе), 
удостоверьтесь, что не генерируются конфликтующие значения ключей. В про- 
тивном случае вам обеспечен длительный сеанс отладки. Самый простой путь 
избежать конфликтов предусматривает применение собственной системы про- 
странств имен. В предыдущем примере все ключи кэша снабжаются префиксом 
в виде специального константного значения, которое гарантированно не совпадет 
ни с каким другим компонентом приложения. 


Использование расширенных средств кэширования 


Описанных выше функций кзширования, скорее всего, окажется достаточно для 
большинства приложений. Тем не менее, платформа предлагает ряд дополнительных 
возможностей для работы с зависимостями. 


® Зависимости от файлое. Можно устанавливать правило, что элемент устаревает, 


когда изменяется любой файл из заданного набора (на диске). Это удобно, если 
кзптированный объект является представлением в памяти содержимого файла; в 
таком случае при изменении файла на диске необходимо просто удалить кэширо- 
ванную копию из памяти. 


Зависимости от элементое кэша. Можно устанавливать цепочки зависимостей 
от элементов кэша. Например, устаревание злемента А также приводит к устаре- 
ванию элемента В. Это удобно, если элемент В является осмысленным только в 
сочетании с элементом А. 


Зависимости от уведомлений кэша ОГ. Это более сложное средство. Оно позво- 
ляет определять устаревание элемента кэша, когда изменяются резульгаты задан- 
ного запроса 5©Г.. В базах данных ЗСТ, Зегуег 7 и ЗСТ, Зегуег 2000 зто достигается 
с помощью механизма опроса, а в базах данных ЗОГ, Зегуег 2005 и последующих 
версий используется встроенный компонент Зекясе ВгоКег, который позволяет из- 
бежать необходимости в проведении опроса. Чтобы использовать любое из зтих 
средств, придется провести основательные исследования (дополнительные сведе- 
ния по этому поводу можно почерпнуть в книге Рго ОГ. бегоег 2008 Зегхсе ВгоКег 
(Аргезз, 2008 г.)). 


И, наконец, можно указать функцию обратного вызова, которая будет запушена при 
устаревании данного элемента кэша, например. чтобы реализовать специальную систе- 
му зависимостей от злементов кэша. Другой причиной выполнения каких-то действий 
по устареванию элемента кэша может быть необходимость в обновлении устаревшего 
элемента на лету. Это удобно в случае, когда для пересоздания злемента требуется вре- 
мя, но следующего посетителя определенно нельзя заставлять ждать. Однако следует 
помнить, что в данной ситуации фактически создается бесконечный цикл, поэтому зто 
не должно делаться в отношении быстро устаревающих элементов. 

Ниже показано, как модифицировать предыдущий пример для пересоздания каждо- 
го злемента кэша при его устаревании: 
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рур11с зЕклпа беемеюРасе (5 т1па цг1) 
{ 
зЕк1па Кеу = сасрекеуРтеЕ1х + иг1; // Вычислить ключ кзша 
зЕг1ра Вы = (361109) сасъе[кеу]; // Попытаться извлечь значение 
1Е (Бет == по 1) // Проверить, присутствует ли оно в кзше 
{ 
// Реконструировать значение, выполняя действительный НТТР-запрос 
ВЕп1 = пем Мерс11ет® () .Поирфоадбет1па (пут); 
// Кэшировать результат ЕТТР-запроса 
саспе.Тозек® (кеу, Ве, по, РабеТ1ие.МахУа1 ое, 
Тамебрап . ЕкопМ1пафез (15), Сасрет®етРг1ог1у.Могта1, ОпТеепВепотеа); 
} 
тебкаки 6611; // Вернуть извлеченное или реконструированное значение 
} 
у018 ОптемВетотеЯ (з5Ег1пд Кеу, обдес® уа]1ае, СасветеепКетоуеЯВеазоп геазоп) 


{ 


1Е (геазоп == СасретфетВетоуеВеазоп.Ехрагеа) 
{ 


// Заново заполнить кзш 
СееМеЪрРасе (Кеу .ЗоЪзет1па (сасвекеуРкеЕ1х .ТепдеН)); 
} 
} 


Обратите внимание, что функция обратного вызова вызывается вне контекста любо- 
го НТГР-запроса. Это означает невозможность иметь доступ к любому объекту КедоезЕ 
или Везропзе (они просто не существуют и не доступны даже через свойство ЗузЕет. 
Мер .НеерСопеех®.Сигтгеп*), равно как и невозможность сгенерировать какой-либо вы- 
вод, видимый любому посетителю. Единственная причина, по которой предыдущий код 
может иметь доступ к СасБе — наличие в нем собственной ссылки на эту коллекцию. 


Внимание! Остерегайтесь утечек памяти! Когда функция обратного вызова является методом зкзем- 
пляра объекта {а не статическим методом), в глобальном объекте Саспе фактически устанавли- 
вается ссылка на объект, хранящий функцию обратного вызова. Это значит, что сборщик мусора 
не сможет удалить ни сам объект, ни любой из объектов, доступных ему в графе. В предыдущем 
примере Сасъе@ИеюВеаиез Е 5егу1се имеет ссылку только на разделяемый объект Саспе, так 
что здесь все в порядке. Однако если бы вместо зтого хранилась ссылка на объект НеЕрСопфехь, 
в памяти бы присутствовало множество действительных объектов без каких-либо веских причин. 


Карты сайтов 


Практически каждому сайту требуется система навигации, которая обычно отобра- 
жается в виде области навигации в верхней левой части каждой страницы. Это настоль- 
ко распространенное требование, что в АЗРМЕТ 2.0 появилась концепция карт сайтов 
(Це аар)}, которая, по сути, представляет собой стандартный АР[-интерфейс для описа- 
ния и работы с навигационными иерархиями. Он состоит из двух частей. 


® Конфигурирование навигационной перархии сайта в виде одного или несколь- 
ких ХМГ-файлов либо в виде специального класса 51%еМарРгоу1Аег. После этого 
платформа будет самостоятельно отслеживать местоположение посетителя в на- 
вигационной иерархии. 


® Визуализация пользовательского интерфейса навигации с помощью встроен- 
ных серверных элементов управления навигацией или создаваемых собственных 
элементов управления навигацией, обращающихся к АРГ-интерфейсу карт сай- 
та. Встроенные элементы могут выделять текущее местоположение посетителя и 
даже отфильтровывать ссылки, посещение которых ему запрещено. 
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Разумеется, несложно добавить к мастер-странице сайта статические ссылки, на- 
писав простой НТМГ-код, и получить элементарные средства навигации, однако карта 
сайта более предпочтительна, так как поддерживает простое конфигурирование (струк- 
тура навигации наверняка несколько раз поменяется во время и после разработки), а 
также описанные выше возможности. 

Платформа АЗРМЕТ поставляется с тремя встроенными злементами управления на- 
вигацией, перечисленными в табл. 15.4, которые подключаются к конфигурации карт 
сайтов автоматически. К. сожалению, только один из них работает правильно без пол- 
ной инфраструктуры форм серверной стороны, применяемой в АЗРМЕТ \!еБЕогтиз. 


Таблица 15.4. Встроенные серверные элементы управления картами сайтов 


Элемент Может ли использоваться 
Описание 

управления в приложении М\УС? 

З1ЕеМарРа®й — Отображает цепочку навигации (5геадсгиглЬ; меню Да 


типа “хлебные крошки”), показывающую текущий узел 
в навигационной иерархии и его соседей. 


Мери Отображает фиксированное иерархическое меню, Нет (должно размещать- 
выделяя текущую позицию посетителя. ся в дескрипторе <Еогм 

типа ="зетуег">) 
ТгееУ1ен Отображает реализованное уамасир!-кодом иерар- Нет (должно размещать- 
Хическое всплывающее меню, выделяя текущую пози- “ся в дескрипторе <Еотт 

цию посетителя. типа ="зекуег">} 


Учитывая, что злементы Мера и Тгее\еи неприменимы, скорее всего, понадобится 
реализовать собственные МУС-совместимые вспомогательные методы НТМ/Г, для зле- 
ментов управления навигацией, которые будут обращаться к АРГинтерфейсу карт сай- 
тов. Ниже будет приведен пример. 


Настройка и использование карт сайтов 


Чтобы использовать поставщик по умолчанию Хи1515еМарРго\1 дег, щелкните пра- 
вой кнопкой мыши на корневой папке проекта и выберите в контекстном меню пункт 
АЯЧ=> Ме ет (Добавить=>Новый элемент). В открывшемся окне выберите элемент ЗНе 
Мар (Карта сайта) и оставьте для него стандартное имя Ме. з1еещар. 


Совет. Если карта сайта должна быть размещена в другом месте или названа как-то иначе, потре- 
буется переопределить стандартные настройки Хи1 51 ееМарРго\19ег в файле иеЪ . сопЕ 19. 
Например, добавьте следующие строки в узел <зузЕет.меь>: 


<516еМар деРап1ЕРгоу19ег="МуХи1$1+еМарРгоу1Чег" епаб1ед="егие"> 
<ргоу1Аегз> 
<ада паме="Мухи1515еМарРго\у1ег" суре="бузеет. Мер . Хи 51 еМарРгоу1дег" 
31сеМарЕ11е="- /Ео1ег/Муб1ееМарЕ11е.з1%етар" /> 
</ргоу1Чегз> 
</з1ЕеМар> 


Теперь можно заполнить карту Ме . 1еепщар, описав навигационную структуру сай- 
та с использованием ХМГ-схемы, стандартной для карт сайтов: 
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<?хшЪ уегз1оп="1.0" епсод1ра="иЕЕ-8" > 
<з1ееМар хипз="ВЕЕр: / /зсретаз .ш1скозоЕ®. сош/ АзрМее/ 51 ееМар-Е11е-1.0" >» 
<з1ееМарМ№оде пг1="-/ " &151е="Ноше" Чезсекёрелоп=""> 
<з1%еМарМоае иг1="-/Ноше/Ароце" &11е="Абоце" Чезст1ре1оп="А1] абоце из"/> 
<81ееМарМоде иг1="-/Нопе/АпофВехг" &1%61е="бомеер1та ефзе"/> 
<з1$еМарМоае иг1="ВЕфр://ими.ехашр1е.сош/" +151е="Ехатр1е. сом" /> 
</з1ЕеМарМ№оде> 
</з1ееМар> 


Затем можно поместить встроенный элемент управления 516 еМарРа\| на мастер- 
страницу: 
<азр:51ЕеМарРаеВ гопа&="зекуег"/> 


Этот элемент отобразит текущее местоположение посетителя в навигационной ие- 
рархии (рис. 15.10). 


Рис. 15.10. Элемент управления 51+ еМарРафв 


Создание специального элемента управления 
навигацией с помощью АР!-интерфейса карт сайтов 


Навигационные цепочки очень удобны, но вдобавок может понадобиться и некоторое 
меню. Построить специальный вспомогательный метод НТМЕ, который получает нави- 
тационную информацию с использованием класса 51ееМар. довольно легко. Например, 
поместите приведенный ниже код класса в любое место приложения: 


рор11с збаф1с с1азз 516еМарНе1фрегз 
{ 
роБ11с эбае1с уо1а КепдегМауМепа (&61$ Неш1Не1Трег В®1) 
{ 
Нет1ТехеМг1еег мг1фег = пем 
Не Техеиг1 ег (Вет. УтеиСорсехе.НеЕрСопеехе.Кезропзе.Опери®) ; 
КепдегВесакз1уе (мг1($ег, 516еМар.Коо%Моде) ; 
} 
рглуафее зфаЕ1с уо1а ВепаетВесигз1уе (Не ТехеМт1еег иг1феег, 516еМарМоде поде} 
{ 
1Е (516еМар.СиггепЕМоде == поде} // Выделить местоположение посетителя 
итг1еег.ВерегВед1иТасд (Нем1ТехЕИт1еегТад.В);// Визуализировать в виде 
// полужирного текста 
е? зе 
{ 
// Визуализировать в виде ссылки 
иг1 тег. АЗЗАЕЕЕ1Юосе (Ни ТехМглеекАеек1Юоее.Нге{, годе.0:1); 
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иг1Сег.ВепдегВед1юТад (Нет1ТехеИт1еегТаа.А); 
} 
мтафег.Иглее (поде.т1(1е); 
мг1сег.ВепдетЕпаТач (); 
// Визуализировать дочерние узлы 
1Е (поае.С0119Модез .СопиЕ > 0} 
{ 
иг1бег.ВепдехВед1пТас (Неп1ТехЕИт1+егТаа. 01); 
Еогеаср ($1еМарМ№оае св114 1п поде.Ср119Модез} 
{ 
иг1фег.ВБепдегВед1пТад (НЕп1ТехеИг1ЕекТаа.тЪ1); 
ВепаегВесигз1уе (игл®ехг, ср119); 
иг1Еег.ВепдегЕраТач(); 


} 


иг1Сег.ВердегЕпаТас(); 


} 


КепЧегКауМепи() — это расширяющий метод, поэтому он будет доступным на 
определенной мастер-странице или в представлении только после импорта его про- 
странства имен. Добавьте следующий фрагмент в начало вашей мастер-страницы или 
представления: 


<%$@ ПирогЕ Мапезрасе=" пространство имен, содержащее класс 51ЕеМарнНе1]регз" %> 


После этого специальный вспомогательный метод НТМГ, можно вызывать, как пока- 
зано ниже: 


% НЕ .ВепаекМауМеот (); $%> 


В зависимости от конфигурации карты сайта и текущего местоположения посетите- 
ля, этот вызов приведет к визуализации приблизительно такой разметки: 


<а вгеЕ="/">Ноте</а> 
<и1> 

<11><6>АБоиЕ</р></11> 

<11><а ВкеЕ=" /Ноце/Апофрег"> бое В1та е1зе</а></11> 

<11><а ВгеЁ="ВЕ®р: //ити.ехатр1е .сош/">Ехапр1е.соп</а></11> 
</и1> 


Разумеется, при желании можно добавить любое форматирование, С$$ или сцена- 
рии клиентской стороны. 


Генерация ЦВЕ карты сайта из данных маршрутизации 


Стандартный поставщик карт сайта АЗРМЕТ, Ххи1515еМарРгоу1 дек, ожидает указа- 
ния явного ОК! для каждого узла карты сайта. Класс Хи151ееМарРхго\1Аег был пред- 
шественником новой системы маршрутизации. 

Однако в приложении АЗРМЕТ МУС лучше не указывать явные ОБ, а взамен гене- 
рировать их динамически, согласно конфигурации маршрутизации. Для этого содержи- 
мое МеЪ . =15ептар понадобится заменить следующим кодом: 


<?хт1 уегз1оп="1.0" епсодлпа="оеЕ-8" 2> 
<з1СеМар хп1пз="ВЕЕр: //зсВетаз .п1скозоЕЕ .сот/АзрМее/$1теМар-Е11е-1.0" > 
<51%6еМарМоае &1&1е="Ноше" сопеёго11ег="Нопе" асф1оп="Тидех"> 
<51{еМарМоде +1&1е="Ароце" сопего}1ег="Ноше" асЕ1оп="АБонь" /> 
<в1ееМарМоае +141е="Ъод 1п" сорбко11ег=“Ассоцп®" асефоп="Тодов"/> 
</з1еМарМоде> 
</з1ЕеМар> 
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Обратите внимание, что в этой конфигурации нет жестко закодированных ОВГ.. Эта 
конфигурация не будет работать со стандартным поставщиком Хи15$1ЕеМарРгоу1дег, 
поэтому следует создать специальный поставщик карты сайта. Добавьте в проект сле- 
дующий класс: 


рур11с с1аз5 Вои(11п951ЕеМарРхоу1Аег : Зкак1с$1теМарРгоу1Аег 


{ 
рглуасе 51ееМарМоде гоо(Моде; 


рыБ11с оуегг14е уо18 То1Е1а11=е (3Ег1пд папе, МашеУааеСо11есЕ1от акег1ЬиЕез) 
{ 


фазе. 101Е1а117е (паме, асех1босез); 


// Загрузить ХМГ-файл, взяв имя из меб. сопЕ19 

// или выбрав Иер.з1Еешар как имя по умолчанию 

уаг хи1Рос = пем Хи1Босищепе (); 

уаг з1ЕеМарЕ11е = акЕт1рикез ["516еМарЕ11е"] ?? "-/меь. з1еетар"; 
хи1 Рос .Гоад (НозЕ1п3Епу1копщере .МарРае\ (31ЕеМарЕ11е)); 

уат гооЕ$1ЕеМарМоде = хт1 Рос .ПосипепеЕ1ещепе ["з1кеМарМоде"]; 


// Построить структуру навигации 
уах ВЕЕрСопеехЕ = пем НЕЕрСопсех(Итгаррет (НЕЕрСопЕех®.Сиггепк); 
уат гедиезЕСортехе = пеи КедиезЕСопеехЕ (ВЕЕрСоптехЕе, пеи Вопеерака()}; 
тоосМоде = АЗаМ№одевесигз1уе (хооЕ$1ЕеМарМоде, пи11, теаиезСортехЕ) ; 
} 


ргтуасе эбаф1с зсг1ид[] гезехуедМатез = пеи[] {"Е1Е1е", "аезстлре1оп", "го1ез"}; 
ре1уасе $З1еемарМоде АЯдМодевеситгз1уе (Хи1Моде хи1Моде, $1ееМмарКоае рагепе, 
КедиезЕСопсехЕ сопкехЕ) 
{ 
// Сгенерировать ОВЪ узла, опросив КопееТаЪ1е.Коикез 
уатг гопсеуа1аез = (Ехом Хи]Моде абЕт1Ь 1п хи1Моде.Акек1ЪБиакез 
иреге !гезегуе Мащез .Сопба1пз (ас ск1Ъ .Маше.ТоЪомех () ) 
зе1есё пеи { асЕег1Ъ.Маще, абсг1Ь.Уа1ое }) 
.Тор1сЕ1опаку(х => х.Маше, х => (обЗесЕ)х.Уа1ае); 


уат гкоцеер1се = пеи ВочееУа1иер1сЕ1опаку (хоокеУа1тез) ; 
уаг ик1 = ВоофеТа1е .Боцеез .бес\1тусиа1Рать (соптехе, гонеерусЕ)} .Узкекнца1рРаки; 


// Зарегистрировать данный узел и его дочерние узлы 
уаг Е1Е1е = хи1Моде.Абсет1рокез ["Е1Е1е"] .Уа1е; 
уаг по4е = пем $1(еМарМоде (+115, Си1Я.Меиби19 () .Тобет1па(), их1, &161е); 
разе.АдаМосде (годе, рагеп®); 
Еотеасв (Хи1Моде сЬ119Моде 1п хи1Моде.Св119М№одез} 
АааМодевВесотз1уе (ср119Моде, поде, сопеехь); 
тегогп поае; 


} 


// Эти методы вызываются АЗР.МЕТ для извлечения данных карты сайта 
рготестей оуегг1Ае 51ееМарМоде бесВооЕМодеСохге (} { хекиги гообМоае; 
руб11с оуегг14е 51ЕеМарМоде Ви11951ЕеМар() { тебагп хооЕМоде; } 

} 


Активизируйте специальный поставщик карты сайта, добавив следующий фрагмент 
в узел <зузеет.меб> файла меь. сопЕ1оа: 


<51сеМар деЁач1ЕРгоу1аетг="МуРгоу1дек"> 
<ргоу1детз> 
<с1еак/> 
<ааа пате="МуРтоу10ет" Еуре="Машезрасе.ВойЕ1п9$1ЕеМарРхоу13=к"/> 
</ргоу1аегз> 
</з1теМмар> 
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Это требует несколько большей работы, чем простое применение встроенного в 
АЗРМЕТ поставщика карты сайта, однако оно того стоит. Теперь элементы карты сайта 
можно определять в терминах произвольных данных маршрутизации, не кодируя же- 
стко ОК. Всякий раз, когда конфигурация маршрутизации изменяется, вместе с ней 
меняется и пользовательский интерфейс навигации. В файле карты сайта можно ука- 
зывать не только контроллера и действия, но и любые специальные параметры мар- 
шрутизации, а соответствующие ОВ, будут генерироваться согласно конфигурации 
маршрутизации. 


Ограничение прав доступа 


В картах сайтов поддерживается средство ограничения прав доступа. Его идея со- 
стоит в том, что каждый посетитель должен видеть только ссылки на те части сайта, 
доступ к которым ему разрешен. Чтобы включить это средство, измените регистрацию 
поставщика карты сайта следующим образом: 


<з1ЕеМар аеЕаз1ЕРгоу1Чег="Мургоу1аег"> 
<ргоу1Аег5> 
<с1еаг/> 
<а@4 папе="МуРгоу1Аег" буре="Мапезрасе .Вои1п9$1еМарРкгоу1Чег" 
зесиг1уТк1иароЕпаь1ед="+хце"/> 
</ргоу19егз> 
</з1ЕеМар> 


После этого появляется возможность управлять тем, какие узлы доступны конкрет- 
ному посетителю, переопределяя метод ТзАссезз161етТо0зек() в поставщике карты 
сайта: 


руб11с с1азз ВооЕ1п951ЕеМарРгоу14ег : Зкак1с51ееМарРгко\у1Аег 
{ 
// Остальная часть класса не изменяется 
руб11с оуегг4ае Ьоо1 ТзАссезз151еТо0зег (НЕЕрСопеехЕ сопеехе, 
351семарМоде поае) 


1Е (поае == гооЕМоде) гебогп ские; // Корневой узел всегда должен 
// быть доступным 
// Сюда помещается специальная логика 


} 


Обычный способ сделать это предусматривает добавление атрибута го1ез в каждый 
узел <з1{еМарМоае> и расширение Во 11951{еМарРгоу1дег для обнаружения значе- 
ния этого атрибута и использования метода сопеех®е.Озег.ТзТиКо1е() для проверки 
факта принадлежности посетителя к списку указанных ролей. Пример реализации 
можно найти в загружаемом коде для этой книги. 


На заметку! Амбициозный разработчик может посчитать, что ему удастся избежать конфигуриро- 
вания ролей, а вместо этого запускать фильтры авторизации на целевом действии и опреде- 
лять во время выполнения, разрешено ли посетителю обращаться к каждому узлу карты сай- 
та. Теоретически это возможно, но будет чрезвычайно трудно учесть все варианты настройки 
выбора контроллеров и методов действий, размещения фильтров и определения фильтрами 
авторизации, кому разрешено обращаться к данному действию. Вдобавок эту информацию 
понадобится кэшировать, поскольку производить подобные вычисления заново при каждом за- 
просе будет слишком дорого. 
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Не забывайте, что ограничение прав доступа лишь скрывает ссылки в навигацион- 
ном меню ради удобства. На самом деле это не помешает посетителю явно запросить 
соответствующие ОВГ.. Безопасность сайта не может быть обеспечена без соблюдения 
ограничений доступа путем применения фильтров авторизации. 


Интернационализация 


Разработка многоязычных приложений всегда была нелегкой задачей, но в .МЕТ 
Егате\мюогК предлагается ряд служб, призванных облегчить ее. 


® Пространство имен ЗузЕет.С1оъа11ха1оп предоставляет различные службы, 
связанные с глобализацией (такие как класс Си1ЕогетюЕо), которые могут фор- 
матировать даты и числа для различных языков и культур. 


° Каждый поток МЕТ поддерживает собственные свойства СиггепЕСи1 ге (объект 
Со1боке7ТпЕо, который определяет различные установки форматирования и сор- 
тировки) и Сиггепе ОТСо1Соге (объект Со16огеТоЕо, указывающий, какой язык 
должен использоваться для текста пользовательского интерфейса). 


® Различные методы форматирования строк, учитывающие СохгепеСа1 ге пото- 
ка при визуализации дат, чисел и валют 


® Среда \154ца| ЭбалА1о имеет встроенный редактор ресурсов, который облегчает 
управление переводами строк на разные языки. Во время разработки к этим стро- 
ковым ресурсам можно обращаться через средство пёеШ$епзе, потому что \У15а! 
Зи генерирует класс с отдельным свойством для каждой ресурсной строки. Во 
время выполнения эти свойства вызывают Зузееп.Везоиксез .ВезоигсеМмападег 
для возврата перевода, соответствующего СогкепЕ ОТСо1Еотге текущего потока. 


В АЗРМЕТ МУС \еЬЕогил$ доступны два дополнительных средства глобализации, ко- 
торые теоретически все еще можно использовать в приложениях МУС. 


® Если пометить АЗРХ-объявление <%@ Раде %> атрибутами Со1коге="аоко:еп-0$" 
и 9ТСи1оге="аофо:еп-05", платформа проверит входящие запросы на нали- 
чие заголовка Ассере-Гапдоаде и затем присвоит соответствующие значения 
СихтепЕСо1еоге и Соггепе ОТСи1оте (в данном примере по умолчанию исполь- 
зуя еп-15, если в браузере не указана предпочитаемая культура). 


® Серверные элементы управления можно привязать к ресурсным строкам с помощью син- 
таксиса <азр:Тафе1 гипаЁ="зегуег" Техё="<%$ гезоитгсез :УоикраееоЕВлкев %>"/>. 


В приложениях АЗРМЕТ МУС обычно ни одно из последних двух средств не приме- 
няется. Представления МУС легче строить с использованием вспомогательных методов 
НТМЕ вместо серверных злементов управления в стиле У/еЪЕоги$, поэтому синтаксис 
<$5...5> здесь используется редко. Кроме того, объявления <%@ Раде %> не дадут эф- 
фекта до тех пор, пока не будет визуализировано представление, что слишком поздно. 
если запрошенная посетителем культура должны быть учтена еще во время выполнения 
метода действия. Ниже будут предложены лучшие альтернативы. 

Платформа также позволяет устанавливать два типа ресурсов глобализации. неулач- 
но названных локальными и глобальными. Локальные ресурсы ассоциированы с одним 
специфическим файлом АЗРХ или АЗСХ (\1вца! Эва ю автоматически сгенерирует за- 
полнители ресурсов для каждого серверного элемента управления, что. опять-таки. не 
особенно полезно для приложений МУС). Глобальные ресурсы доступны во всем при- 
ложении. Ради краткости, а также потому, что локальные ресурсы, ориентированные 
на серверные элементы управления, не особенно зффективны в приложениях АЗРМЕТ 
МУС, ниже будут подробно рассматриваться только глобальные ресурсы. 
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Настройка интернационализации 


Настроить интернационализацию в приложении МУС очень легко. Щелкните пра- 
вой кнопкой мыши на проекте в окне ЗоНоп Ехрогег и выберите в контекстном меню 
пункт Ада=>Мем! Нет (Добавить=>Новый элемент}. Выберите Везоигсез Ейе (Файл ресур- 
сов), и назовите файл Кезопгсез .гезх. Добавьте одну или более строк, которые вы хо- 
тите локализовать, — вроде тех, что показаны на рис. 15.11. 


Нате Чаще Соглилевй 
Ееатог ‘врегаое 
дтеебпЗ | нома; 
Ра ^ гра 
ела } эбеина 
‚ ТреЕАЫег ре РееадЕНЕ 


Рис. 15.11. Файл ресурсов для культуры по умолчанию 


Значения, заданные в файле Безоигсез .гезх, будут использоваться в приложе- 
нии по умолчанию. Если понадобится поддерживать другой язык, создайте аналогич- 
ный файл ресурсов с тем же именем, но другим обозначением культуры (например, 
Везоигсез .еп-СВ.хезх или Везоигсез .ги-ВО.тезх). На рис. 15.12 показано содер- 
жимое файла Кезонтсез .еп-СВ .гезх. 


Мате зав ОСРЛИЛЕР 
Евсасг ве 
бтеебад “ва Ва: Ао маги лебоге 
Ранёз ЧЕСИЗЕГЕ | 
ЗЕ раметлем 
[а ТРЕБыег Нег Во! Вбалие Маресьу, Не СЕЙ 
* 


Рис. 15.12. Файл ресурсов для культуры еп-СВ 


После сохранения файла Кезоигсез .хезх специальный инструмент в \15иа! Зав ю 
создаст класс С# в файле Везоигсез .Рез1арег.сз. Помимо прочего, сгенерирован- 
ный класс содержит статическое свойство, соответствующее каждой ресурсной строке, 
например: 


/// <зопахку> 
/// Поиск локализованной строки, аналогичной понятию "Ргез1депе". 
/// </зищаку> 
1п6етгпа1 эзраЕ1с эЕх1па ТБево1екг { 
дее { 
тесаги Везоигсемападет.Сее$Ет1оа ("Трево1ех", гезоцгсеСа1Еоте); 


5 Если хотите следовать соглашениям о папках АЗРМЕТ, создайте специальную папку, пред- 
назначенную для АЗРМЕТ. по имени Арр С1оБа1Везоигсез и поместите туда файл ресурсов 
(Хотя делать это совсем не обязательно). 
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Это почти то, что нужно. Единственная проблема здесь в том, что автоматически 
сгенерированный класс и все его свойства помечены как 1п$егпа1, что делает их не- 
доступными в представлениях АЗРХ (которые компилируются в виде одной или более 
отдельных сборок). Чтобы решить зту проблему, вернитесь к файлу Везоогсез .гезх и 
установите модификатор доступа риБ11с, как показано на рис. 15.13. 


369 бйноз * 1 444 Кезоцисе * Ассезв Моййен Рывбе | ы 
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Мате Уаме «Но соде депегамоп 
Еесакст вегайот 
САУ фене 


Рис. 15.13. Как сделать класс ресурса доступным за пределами его сборки 


Теперь в представлениях МУС к ресурсным строкам можно обращаться строго типи- 
зированным, поддерживающим средство шлеШ$еп$е способом (рис. 15.14). 
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Рис. 15.14. Средство еШЗепзе поддерживает работу с ресурсными классами 


Во время выполнения ВезоигсеМападег извлечет значения, которые соответству- 
ют кульгуре, указанной в Сигхеп  ОТСи16иге текущего потока. Но как определяется 
эта культура? По умолчанию она берется из настроек ОС УЯЛпао\з на сервере, но часто 
требуется варьировать культуру для каждого посетителя, проверяя входящий заголовок 
Ассер&-Тапацаде для определения его предпочтений. 

Один из способов достижения этого, который отлично работает, если предпочи- 
таемую культуру посетителя нужно учитывать только при визуализации шаблонов 
представлений АЗРХ, состоит в добавлении атрибута ОТСи1Еихе="аоко" к директиве 
<%@ Раде %> представления. Это не слишком удобно, если учитывать культуру посети- 
теля необходимо во время выполнения метода действия или при визуализации пред- 
ставлений с использованием других механизмов. Возможно, лучшим решением будет 
добавление следующего кода в файл С1оБа1.азах.сз: 


ргосесгеа уо1а Арр11саЕ1оп Вед1пВечиезе (ою]есЕ зепаетг, ЕуепЪАгаз е) 
{ 
// Используется код МерРогиз для применения "автоматически выбираемой" 
// культуры к текущему потоку и автоматической обработки запросов 
// недопустимой культуры. 
// По умолчанию принимается еп-0$. 


13109 (уаг ЕакеРаде = пеи Раде()}} { 
уаг 1дчтотеЯ = ЕакеРаде.5етуег; // Обойти причуды ИебРогтз 
ЕакеРаде .Со1еоге = "апбо:еп-Ч5"; // Применить локальное 
// форматирование для зтого пстока 
ЕакеРаде.0ТСо1фиге = "апбо:еп-05"; // Применить локальный язык 


// для зтого потока 
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При желании проверять значения входящего заголовка Ассер®-Тапдишаде можно и 
вручную, используя для этого Ведиезе .ИзегТапдиасдез, но следует иметь в виду, что 
клиенты могут запрашивать несуществующие или некорректные установки кульгуры. 
В предыдущем примере показано, как вместо разбора заголовка и обнаружения некор- 
ректных запросов кульгуры вручную можно воспользоваться уже реализованной логи- 
кой класса Расе из \еБЕогиа®. 

Теперь в зависимости от того, какой язык сконфигурировал посетитель в своем брау- 
зере, он увидит одну из страниц, показанных на рис. 15.15. 
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Рис. 15.15. Вывод для примера интернационализации 


Окно, показанное справа, соответствует установке браузера еп-СВ, а слева — лю- 
бой другой установке. Дата и обозначение валюты форматируются с использованием 
Расе.Тобпог& Рае Е г1па() и зЕк1па .Еогмах ("{0:с}", 1) соответственно. 


Советы по работе с файлами ресурсов 


Все приложения, кроме самых небольших, выигрывают от хранения ресурсов в от- 
дельной сборке. Это облегчает их длительную эксплуатацию и означает возможность 
ссылаться на них из других проектов. 

Для этого создайте новый проект библиотеки классов, щелкните правой кнопкой 
мыши на его имени и выберите в контекстном меню пункт АЯ Меми {ет (Добавить=> 
Новый элемент) для добавления файла .гезх в точности так, как это делалось раньше. 
Все достаточно легко. Только не забудьте указать \150а! Зил 10, что генерируемые клас- 
сы должны быть помечены как риЪ11с (см. рис. 15.13). Это сделает их доступными в 
других проектах решения. 

Существует еще один трюк, о котором следует упомянуть. Вместо того чтобы по- 
стоянно набирать ПроектРесурсов.Везоигсез .5отеЕН1та при редактировании пред- 
ставлений МУС, добавьге в файл меь . сопЕ19д следующую глобальную регистрацию про- 
странства имен, после чего можно будет писать просто Везоиксез . Зошеев1 пс: 


<зузсет.мер> 
<радез> 
<папезрасез> 
<аЯ9а патезрасе="ПроектРесурсов" /> 
</папезрасез> 
</радез> 
</зузЕет.мер> 
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Использование заполнителей в ресурсных строках 


Само собой, в реальных сценариях интернационализации на разные языки долж- 
ны переводиться целые фразы, а не только отдельные слова представляться на разных 
диалектах. Внутрь этих фраз часто придется вставлять другие строки, которые будут 
извлекаться из базы данных или вводиться пользователем. 

Обычное решение таких задач предусматривает комбинирование средств интерна- 
ционализации платформы с метода 5Ет1п9ч.Еогтаф () и применение пронумерованных 
заполнителей и средства комментариев (Согитепй) редактора ресурсов, которое позво- 
ляет объяснить переводчикам, что означает каждый заполнитель. Например, ресурс- 
ный файл по умолчанию может содержать заполнители, показанные на рис. 15.16. 


Мате заме СоглилеНЕ 
‚Узердатаа Те цзег {0 лаз ираавей а (Илит 9 {8} = изеглагле, {11 = иле ирфаеЯ 


Рис. 15.16. Ресурсный файл с заполнителями 


На основе зтого переводчики смогут создать файл ресурсов для испанского языка, 
как показано на рис. 15.17. 
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Рис. 15.17. Ресурсный файл для культуры ез-Е$ 


После этого можно визуализировать локализованную строку из представления сле- 
дующим образом: 


<$= зЕглпа.Рогтае (Кезоигсез.ОзекОрдакей, \У1еирагка["ОзетМате"], Расетлие.М№\и) $%> 
В резульгате получится: 
Тре изег "ВоБ" маз ирдасеа аф 1:46 РМ 


Но для испаноязычных посетителей увидят следующий вывод: 
(13:46) ЕТ изиаг1о "Воф" Ва $3140 аскаа11хадо 


Обратите внимание, насколько легко меняется структура предложений и даже исполь- 
зуются разные стили форматирования. Полные фразы могут быть переведены намного 
яснее, чем индивидуальные фрагменты предложений наподобие “\уаз ираафе4 а”. 

Если интернационализация играет важную роль в разрабатываемом приложении. 
то понадобится учесть и другие моменты, например, проектирование для языков с 
письмом справа налево, а также поддержка календарей, отличных от григорианско- 
го. Дополнительные сведения об интернационализации можно найти в книге „МЕТ 
Пуетайопайлайоп (Азот \\е$Гу, 2006 г.). 


Производительность 


В оставшейся части этой главы вы ознакомитесь с некоторыми приемами повыше- 
ния, мониторинга и измерения производительности приложений АЗРМЕТ МУС. Все они 
построены на применении базовых средств платформы АЗРМЕТ. 
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НТТР-сжатие 


По умолчанию платформа МУС отправляет данные ответа браузеру в простом, не- 
сжатом формате. Например, текстовые данные (НТМГ.-разметка) обычно посылаются 
в виде байтового потока ОТЕ-8: это более эффективно, чем ОТЕ-16, но далеко не так 
плотно упаковано. как могло бы быть. Почти все современные браузеры воспринимают 
данные в сжатом формате и сообитают о своей способности принимать их, отправляя 
заголовок АссерЕ-Епсо@1п4 с каждым запросом. Так, например, и Еигеюх 3, и Бцегтей 
Ехрогег 7 посылают следующий НЛТР-заголовок: 


Ассерс-Епсод1та: 971р, де асе 


Это значит, что они способны воспринимать нюбой из двух основных алгоритмов 
ЕИТР-сжатия — 92ф и аеЛае. В ответ веб-приложение должно отправить заголовок 
СопЕепЕ-Епсо@1п9 с указанием, какой из двух алгоритмов будет использоваться, и за- 
тем полезную нагрузку НТТР (в кодировке ОТЕ-8 или какой-то другой), сжатое с помо- 
щью выбранного алгоритма. 

Пространство имен Зузфещ.ТО.Сопргезз1от в .МЕТ ЕгатеххогК содержит готовые 
реализации обоих алгоритмов сжатия бир и Аейае, так что очень легко реализовать 
любой из них в небольшом фильтре действия: 


15109 Зузбеш. то; 
15109 Зузбеш.ТО.Сошргез51оп; 
рРуЮю11с с1аз5 Епаб1еСотргезз1опАЕт1Босе ; АсЕ1опР11кегАсеуароее 
{ 
соп5Е Сошрхезз1опМоае сопргезз = Сопргезз1опМоде .Сотргезз; 
рыю11с оуект1ае уо1а ОпАсЕ1орЕхеси1та (АселопЕхеси1паСоркехЕ Е11кетСопеехе) 
{ 
НЕесрКедаез{Вазе гедиез® = Е11кетСопеехЕ .НЕЕрСореехе .ВеаиезЕ; 
НеЕрВезропзеВазе гезропзе = Е116етСопеехЕ.НеерСоптеехе .Везропзе; 
3Ег1ид ассерЕЕпсоЯ1та = гедиезе.Неадетз ["Ассер*-Епсо@1та"] ; 
1Е (ассерЕЕпсо@1та == по11) 
тебати; 
е1зе 1Е (ассерЕлсоЯ1та.ТоЪомег() .Сорка1 из ("д71р") } 
{ 
тезропзе.Е11{ег = пеи 621р5егеап(гезрорзе.Е11еег, сопргез5); 
тезропзе .АррепаНеааех ("СопсерЕ-Епсо@1та", "д71р"); 
} 
е15е 1ЁЕ (ассерЕЕпсоа1иа.Тофомех() .Сопра1тз ("аеЕ1аке") ) 
{ 
тезропзе.Е11{1етх = пеи БеЕ1атебегеан (тезропзе.Е11кех, сопргезз); 
тезропзе.АррепаНеааег ("Сопееп®-Епсо@1та", "аеЕ1аке"}; 


} 

} 

В этом примере фильтр выбирает алгоритм сжатия 571ф, если браузер поддерживает 
его, а в противном случае переключается на аеЙае. После оснащения одного или более 
методов действия или контроллеров атрибутом [ЕпаЪ1еСотргезз1оп] нагрузка на про- 
пускную способность существенно сократиться. Например, следующий метод действия 


[Ераб1еСопрхез$1оп] 
риуБ11с уо1а тпаех (} 
{ 


// Вывод большого объема данных 
Бог (ет = 0; 1 < 10000; 1++) 
Кезропзе.Итглее ("Не11о "+ 1 + "<Ьх/>"); 
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без атрибута [ЕпаБ1еСопргезз1от] порождает около 149 Кбайт полезной нагрузки, а 
теперь эта нагрузка сократится до 34 Кбайт, те. экономия превысит 75%. Скорее всего, 
реальные данные не будут упаковываться настолько хорошо, но исследование, прове- 
денное на 25 ведущих веб-сайтах, свидетельствует, что НТТР-сжатие обеспечивает эко- 
номию сетевой нагрузки до 75%7. 

Сжатие экономит загружаемый объем данных, и потому страницы загружаются бы- 
стрее, а пользователи более счастливы. Кроме того, в зависимости от применяемого па- 
кета хостинга, экономия объема данных может означать экономию денег Однако имей- 
те в виду. что сжатие оплачивается временем центрального процессора. Понадобится 
оценить, что важнее: загрузка процессора или сокращение объема передаваемых дан- 
ных. Решение относительно приложения должен принимать разработчик. Сжатие мо- 
жет оказаться целесообразным только для определенных методов действий. Если вы 
комбинируете его с кэшированием вывода, то можете сократить и объем данных, и за- 
грузку процессора, правда, за счет расходования дополнительной памяти. 

Не забывайте, что НТТР-сжатие действительно полезно только для текстовых дан- 
ных. Двоичные данные, такие как графика, обычно уже сжаты. Какого-либо выигрыша 
от сжатия по алгоритму 57р данных, уже сжатых в формате ЧРЕС, не будет, но бессмыс- 
ленная нагрузка на процессор возникнет 


На заметку! Сервер ИЗ 6 и последующих версий можно сконфигурировать для НТТР-сжатия посы- 
лаемого в ответ статического (т.е. файлов, взятых непосредственно с диска} или динамического 
содержимого (например, вывода из приложения АЗРМЕТ М\УС). К сожалению, конфигурировать 
зто довольно трудно (понадобится непосредственно редактировать метабазу 5, что может ока- 
заться недоступным в некоторых сценариях развертывания}, и, конечно, это не даст возможно- 
сти индивидуального включения и выключения сжатия для отдельных методов действия. 


Трассировка и мониторинг 


Несмотря на то что обычно больше смысла оптимизировать приложение для со- 
провождаемости и расширяемости, чем для производительности (серверы дешевле 
разработчиков), все же при кодировании не стоит упускать из виду ряд показателей 
производительности. 

Метод действия, выполнявшийся ранее за 0,002 секунды, после внесения изменений 
вдруг стал выполняться за 0,2 секунды. Вы заметили зто? Возрастание времени в 100 
раз может оказаться критичным для приложения, находящегося под рабочей нагруз- 
кой. Или, скажем, предполагается, что некоторый метод действия запускает 1 или 2 
запроса к базе данных, но иногда он выполняет 50 запросов — это не очевидно во время 
разработки, но будет критичным в рабочей среде. 

Проведение специального тестирования нагрузки, конечно же, полезно, но к зтому 
моменту основной код уже написан и, возможно, поверх него уже пишется дополни- 
тельный код. Чем раньше удастся заметить основные проблемы производительности, 
тем больше будет сэкономлено усилий. 


8 Размер загруженной страницы можно посмотреть в браузере ЕшеЮх 3. Для этого щелкните 
правой кнопкой мыши на странице и выберите в контекстном меню пункт Ме\м Раде по 
(Информация о странице). Размер страницы отображается в поле Зе (Размер) на вклад- 
ке Сепега! (Основная). Однако не обращайте внимания на значение размера, сообщаемое 
Пцегпеё Ехрогег (для этого щелкните правой кнопкой мьши на странице и выберите в кон- 
текстном меню пункт Ргорег вез (Свойства)} — он всегда показывает размер страницы после 
развертывания сжатых данных. 


7 5рееа Ор Уоиг 5йе: МЕБ 5йе Оритгайоп, Апагех Капа (Ме\х7 Еааегз Ргезз, 2003 г); 
уии . иер$1теоре1и1 талой .сом/ зрееа/18/18-2Е.Н1. 
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К счастью, в каждой части стека приложения доступны инструменты, которые по- 
могут отслеживать, что происходит внутри самого приложения. 


е АЗРМЕТ имеет встроенное средство трассировки, которое добавляет значитель- 
ный объем статистики по обработке запросов в конец каждой сгенерированной 
страницы, как показано на рис. 15.18. К, сожалению. в основном она предназна- 
чена для приложений АЗРМЕТ УеЪЕогиз: большая часть информации о времени 
представлена в терминах серверных злементов управления и событий жизненно- 
го цикла страниц. 

Для включения трассировки понадобится добавить следующую строку в узел 
<зузеем.иеЪ> файла иеЪ . сорЁ1 в: 


<Егасе епабЛед="е гие" радебисриЕ=“"&хие"/> 


Кроме того, доступное в АЗРМЕТ средство мониторинга работоспособности по- 
зволяет протоколировать или иначе обрабатывать каждый запуск или останов 
приложения, каждую обработку запроса и каждое событие опроса состояния (под- 
тверждающее, что приложение реагирует на запросы). За дополнительными све- 
дениями о мониторинге работоспособности обращайтесь на страницу МОМ по 
адресу Веер: / /шз@п .плскозоЕЕ.сош/еп-из/11Ъгагу/тз998306.азрх. 


® Сервер Н$, подобно большинству веб-серверов, ведет зкурнал НТТР-запросов, ото- 
бражая время, потраченное на обработку каждого из них. 


® Инструмент профилирования ЗСТ, Зегуег Ргоег, будучи запущенным, протоколи- 
рует все запросы базы данных и показывает статистику выполнения. 


® Сама ОС УЛпао\з располагает встроенными средствами мониторинга произво- 
дительности — утилита рекЕтоп позволяет протоколировать и строить графики 
использования процессора, памяти, дисковой активности, сетевого трафика и 
многого другого. В ней есть даже специальные средства для мониторинга прило- 
жений АЗРМЕТ, включая количество перезапусков приложения, исключений „МЕТ, 
обработанных запросов и тд. 


В общем, возможностей существует немало; важно только научиться получать не- 
обходимую информацию. Тем не менее, не всегда очевидно, как получить только самую 
нужную информацию и как сделать видимыми без особых усилий необходимые показа- 
тели в процессе разработки (и каким образом заставить коллег делать то же самое). 


, 
} 


Зезчой 14: 
кие о Ведиез т: 


БЕ ОРЕХРОН ЗСУ 5 Кедие5Е Туре: 
06496,2008 13:24:21 5ани Соде: 200 


Везтие51 ЕпссйНа: Эгисо4е ГТЕ-8% Ви: Оысоде 7УТЕ-8' 
Тгасе и\Могтацоп Я 


| 
НО 
ы Сатедоту Его 2955 Его Раб} 
}{ азрх.раде Ведйл РгамИ: 
|? аврх.раве Еп@ гели 0.0262504033333845 5.026250 
} аврх.раде Беби ВЕ 0.0252980350854648 0.000045 
$ азрх.раде БАЗ АА 0.0263231779458004 8.080625 
}1 азрх.раде Веди тпиСогарее 0.0253418954084947 0.000019 
|} азрхфраде Епд аНсотр ее 0.0263605827124675 5.000019 } 
НН аврк.раде Ведя Ргароа@ 0.02635787017623748 0.000038 р 
: 


- 


Рис. 15.18. Встроенное средство трассировки АЗР МЕТ 


Глава 15. Компоненты платформы АЗРМЕТ 531 


Мониторинг времени генерации страниц 


Для организации быстрого и простого отслеживания показателей производительно- 
сти можно создать специальный модуль НЛТР, который добавляет статистику произво- 
дительности в конец каждой генерируемой страницы. Модуль НТТР — это просто класс 
„МЕТ, реализующий интерфейс ТНЕЕрМоди1е; его можно поместить в любое место реше- 
ния. Ниже приведен пример применения встроенного в .МЕТ класса таймера высокого 
разрешения Зузсет.01а9поз(1с3.56ориа®сьЬ: 


руБ11с с1азз РегЕогхпапсеМоп1ЕохМови1е : ТНЕЕРМодо1е 
{ 


риЮ11с у019 О15зрозе() { /* Ничего не делать */ } 


риБ11с \у014 Та1 6 (НЕБрАрр]11саб1оп соп®ехЕ) 
{ 
сопсехф.Ргекечиез(Напд1ехЕхесисе += де1едате (ою)есе зепдех, ЕуепбАгоз е) 
{ 
НЕЕрСопеехе гечиез®СопсехЕе = ((НЕбрАрр11сас1оп) зепдег) .СопфехЕ; 
Зсормаесв Е1щег = пем Зсормабсь (); 
теаиез(Соп®ехЕ .Теепз ["Тзпех"] = блек; 
Е1щег.Збагк® (); 
}; 


сопсех®.Ро5(ВедиезНапо1ехЕхесисе += ае1едабе (об)есЕ зепдег, Еуеп%Агаз е) 
{ 
НесрСопсехе гечиезеСопеехе = ({(НЕбрАрр11са(1оп) зепдег)} .СопфехЕ; 
ЗбориаесН Е1шегк = (5бормассВ) гедиез®Сопфехь. Теемз ["Т1мшег"]; 
Слмег.ЗЕор (); 


// Не вмешиваться в ответы, отличные от НТМГ, 
1Е (геацезеСопсех®.Везропзе _СопберпЕТуре == "кехе/вси1") 
{ 
ЧочЮ1е зесопаз = (аоцЬ1е) 1пег.Е1арзедТ1ск$ / ЗкориассВ.Егеаиепсу; 
зЕг1п9 кези1е = 
зЕг1па.Еогща® ("{0:Е4} зес ({1:Е0} хед/зес)", зесопдз, 1 / зесопдз); 
хечиез{Сопсехе .Везропзе.ИМг1(е ("<Вуг/>Тлие бакеп: " + гезо16); 
// Вывод времени в секундах 


}; 
} 
} 


Классы, реализующие ТНЕЕрМоби1е, должны быть зарегистрированы в файле меь. 
сопЕ19 приложения, в узле вроде следующего: 


<а4а папе="РегЕМоди1е" 
туре=" ПространствоИмен. РегЕохтапсемот1СогМод1е, ИмяСборки"/> 


Для сервера П$ 5/6 и встроенного в \1зиа! ЭбаАю веб-сервера добавьте такой узел в 
раздел зузсет.мею/ВеерМоаи1ез, а для сервера П$ 7 — в раздел зузкеп.мебзекуек/ 
подо1ез (или воспользуйтесь диспетчером служб ПЗ 7). 

После регистрации модуля РегЕогиапсеМоп1согМоаи1е на страницах будет выво- 
диться статистика по производительности, как показано на рис. 15.19. 

Даже одни эти статистические данные являются ключевым индикатором производи- 
тельности. Встраивая их в приложение, вы автоматически разделяете свои намерения 
с другими разработчиками команды. Перед развертыванием приложения на рабочем 
сервере просто удалите (или закомментируйте) модуль в файле меь.сопЁ19. 
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Рис. 15.19. Вывод из модуля РехЕохтапсеМот1 согхМода1е, добавленный к странице 


: Типе аКеп: 0.000 сес (226$ гехузес) 


Мониторинг запросов базы данных ММО фо $01 


Помимо времени генерации страниц наиболее важные показатели производитель- 
ности обычно касаются доступа к базе данных. За считанные миллисекунды может 
выполняться, скажем, 100 запросов к персональному экземпляру ЗОЕ Зегуег, но если 
рабочий сервер будет нытаться делать то же самое для 100 параллельно работающих 
клиентов, возникнет серьезная проблема. 

К тому же, при использовании инструмента ОКМ, подобного ММО фо З©Е, иногда 
теряется чувство реальности. Несмотря на то что при этом писать вручную много кода 
ЭО@Е, не приходится, масса запросов ЭОЁ все равно выполняется. Но как узнать, сколько 
именно таких запросов выдается, и насколько они оптимизированы? А, может, возник- 
ла известная проблема ЗЕТЕСТ № +18? 

Один из вариантов предусматривает использование инструмента ОГ. Зегуег Рго@ет, 
который отображает каждый запрос в реальном времени. Однако это означает необхо- 
димость запуска ЗСТ, РгоЙег и нериодического просмотра выдаваемой им информации. 
Даже при наличии специального монитора, выделенного под ЗОГ, Рго@ет, довольно труд- 
но определить. какие запросы базы данных связаны с конкретным НТТР-запросом. К, 
счастью, в ММО о ЭОЕ ведется внутренний журнал запросов, поэтому можно написать 
модуль НТТР, который покажет запросы базы данных, произведенные в рамках каждого 
НТТР-запроса. Такой подход намного удобнее. Добавьте в решение следующий класс: 


руБ11с с1азз 5а1РехЕогхтапсеМоп1охМодиа1е : ТНЕЕрМода1е 
{ 
зфафлс зСг1па[] Оцехгуб$еракафох 
= пем $6:109[] { Епу1копмеое .МемЬ1пе + Епузкопмепе.Меизпе }; 
роБ11с уо1а То1Е (НЕбрАрр11сае1ой сопфехЕ) 
{ 
сопсехе.РгеВедаез Нап 1етЕхесиее += Зе1едасе (оБ)ес® зепдек, ЕуепфАгаз е) 
{ 


// Подготовить новый пустой журнал 
НебрСопсехЕ ВЕЕрСопеехЕ = ((НЕбрАрр11саЕ1оп) зепдет) .СопфехЕе; 
ВесрСопсехе . Тбемз ["11па9Тоба1Год"] = пем 56 х1о9Ихлфех (); 


}; 


8 Проблема ЗЕТЕСТ №+1 означает сценарий, при котором инструмент ОБМ загружает список 
из № объектов (одним запросом), а затем для каждого объекта в списке выполняется отдель- 
ный запрос для загрузки некоторого связанного объекта (те. еще № запросов). Конечно, вые 
дача такого количества запросов крайне нежелательна. Решение состоит в конфигуриро- 
вании стратегии опережающей загрузки (еабег-1оа91115), чтобы объединить все связанные 
объекты в рамках исходного запроса, сводя процесс загрузки к выполнению одиночного 
запроса ЗОГ. В ИМО ю ЗОЕ зто поддерживается через понятие расаТоадОрЕ1опз- 
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сопфехе.РозЕВеоиез(НапЯ1етЕхесиве += де1едате (об]есе зеп@етг, ЕуепфАгаз е) 
{ 
НЕсрСопеехе РЕЕрСопЕехе = ((НЕрАрр]1саЕ1оп) зепдет) .СопсехЕ; 
НЕЕрВезропзе гезропзе = ВЕЕрСопеехе.Везропзе; 
// Не вмешиваться в ответы, отличные от НТМГ, 
1Е (гезропзе.СорбепЕТуре == "бехе/БЕи1") { 
уаг 109 = (56 глпоме1 бек) БЕЕрСопСехе . Кетз ["11раТоба]Точа"]; 
уат чцет1ез = 1о9.ТобЕхг1па () .5р116 (Оцегу$еракакокг, 
$ЕЕ1195р11СОрЕ1опз .ВетоуеЕтреуЕпсг1ез); 
ВепдегОцеглезТоВезропзе (хезропзе, даег1ез); 


}; 
} 
уота ВепдегОцет1езТоВезропзе (НЕЕрВезропзе гезропзе, 5&г1п9[] ацег1ез} 
{ 
тезропзе.Иг1е ("<@а1у с1азз='РегЕогтапсеМоп1$охг!>") ; 
гезропзе .Игз{е (5Ех1п9.Еогма® ("<Б>Ехесифеа {0} $0Ъ {1}</ъ5>", 
ааег1ез.Герафь, 
ацег1ез .ТепдёВ == 1 ? "ацщеку" : "ацеглез")); 
тезропзе. Их Ее ("<о1>"); 
ЕогеасВ (уах епбкгу 1п ацег1ез) 
тезропзе .Иг1е (зЕу109.ЕКогтаф ("<11>{0}</11>", 
Ведех .Вер1асе (еп гу, " (ЕВОМ|ИНЕВЕ|--)", "<Ьг/>$1"))); 
гезропзе.Иг1{е ("</о1>"); 
гезропзе. Ик фе ("</алу>"); 


} 
рУб11с уо1@9 Г1зрозе() { /* Не требуется */ } 
} 


Как обычно, модуль НТТР должен быть зарегистрирован в файле иеЪ.соп{19, либо в 
разделе зузсем. мер /вЕЕрМоди1ез для ПЗ 5/6 и встроенного в \1з0а1 56л1ю веб-сервера, 
либо в разделе зузфет.меб$егуег/поди1ез для ПЗ 7. Ниже показан синтаксис: 


<а4а пате="$а1РехкЕ" 
фуре=" Пространствоймен. $41РехЕогиапсеМмоп1 когМоди1е, ИмяСборки" /> 


Этот модуль НЛТР начинает каждый запрос с создания нового объекта 5 г1па9Ихг1 ег 
и сохранения его в коллекции Тфепз текущего контекста НТТР. В конце запроса он из- 
влекает зтот 5Ег1п9Ит1фехк, разбирает помещенные в него данные ЗОГ-запроса, пред- 
принимает попытку красиво сформатировать результат, вставляя переносы строк и 
НТМЕ-дескрипторы, и включает в поток ответа. 

Все это замечательно, но средству ЕЛМО 0 ЗОЕ ничего не известно об зтом, а по- 
тому оно ничего не сможет сообщить о каких-либо запросах. Чтобы получать нуж- 
ную информацию, понадобится внедриться в частичный метод ОпСгеафеа() класса 
РагаСопсехЕ из ММ© фо ЗОЕ. Способ зависит от того, как первоначально создавался 
класс РасаСопфехс. 


® Если класс РафаСопеехе был первоначально создан как файл .а5т1 (с помо- 
щью команды создания нового файла классов ММО №0 ЗОЕ в \\зца! Зил а1о), от- 
кройте этот файл в визуальном редакторе и затем выберите в меню Мем=>Соае 
(Вид>Код) или нажмите <Е7>. \1зиа! З6аа1ю отобразит файл частичного класса, 
представляющего класс РафаСопфех®. Назначьге объект журнала, добавив час- 
тичный метод следующим образом: 
ру611с раге1а1 с1азз Ехапр1ерафаСопфехе 
{ 


// Остальная часть класса не изменяется 
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раг%1а1 уо1А ОпСгеа*еа () 


{ 
уаг сопфехе = НЕЕрСопеех®е.Сиггеп®; 
1Е (сопфехЕ != па11) 
{515.09 = (5&г1ооМтафег) сопфехеЕ. Тфетз ["11паТоба1109"]; 
} 


} 


Если класс РафаСопфехе изначально был создан вручную, как это делалось в при- 
мере приложения Зройзюге, просто присвойте объект журнала его свойству Год: 
уаг ас = пем РабаСопсехе (соппесе1от5 Е т1пд); 

Яс.Т1од = (ЗЕк1поМг1фег) НЕЕрСопеехЕ. Тфетз ["11паТоба109"]; 

уат ргобисе$Тар1е = дс.сСеЕТа1е<Ркодис®> (); 


Это значит, что при каждом создании контекста данных он будет находить 
ЗЕк1паИс1 сек, который был создан $91РегЕогпапсеМоп1СогМоди1е, и использовать его 
в качестве журнала для каждого выполняемого запроса. Аналогично следует поступить 
и с остальными классами РасаСопфех®, если их более одного. 

Полученный резульгат можно видеть на рис. 15.20. 
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Рис. 15.20. Вывод из модуля 591РехЕогиапсеМоп1 согМоди1е, добавленный к странице 


Если вы — новичок в ИМО Фо ЭСЕ и пока не умеете зффективно его использовать. то 
наличие такого журнала значительно прояснит, что происходит на самом деле. А если 
в команде есть разработчики, не доверяющие инструментам ОКМ из опасений за про- 
изводительность, покажите им зто — возможно, их мнение изменится. 


Совет. Особенность классов, реализующих интерфейс тнеЕрМодц1е, состоит в том, что мож- 


но применять любую их комбинацию за раз. Позтому можно было бы использовать модуль 
591РегЕогхиапсеМоп1СохгМо@и1е параллельно с модулем РегЕогиапсеМоп1охМоди1е, 
чтобы отслеживать и запросы ЗСЕ, и количество генераций страниц. Только не забывайте уда- 
лять их из файла меь .сопЁ19 перед развертыванием приложения на рабочем сервере, если 
только не хотите показывать зту информацию широкой публике. 
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Резюме 


В этой главе рассматривались наиболее часто используемые готовые компоненты 
приложений, предлагаемые базовой платформой АЗР.МЕТ, а также способы их приме- 
нения в приложениях МУС. Если вы сможете использовать любые из них вместо изобре- 
тения собственных аналогов, это позволит сэкономить не одну неделю работы. 

В последней главе будет показано, как комбинировать элементы приложения МУС, 
в частности, маршрутизацию, контроллеры и представления, с классическими страни- 
цами \\еБЕогтп$. Такая возможность чрезвычайно полезна при переносе существующих 
приложений \еБЕоги1$ на платформу АЗРМЕТ МУС. 


ГЛАВА 16 


омбинация платформ 
МУС и \ебЕопт$ 


омбинирование технологий АЗРМЕТ МУС и У’еБРогил$ в одном веб-приложении 
понадобится в следующих двух наиболее вероятных сценариях. 


» Разрабатывается приложение МУС, в котором необходимо использовать техно- 
логии УеЕогтпз. Такая ситуация возникает, когда в приложении имеются унасле- 
дованные из ранних проектов страницы УеБРогии$, веб-злементы управления или 
пользовательские злементы управления, но нет времени для их повторной реали- 
зации с помощью технологии МУС. 


® Имеется готовое приложение \еБЕогт$. которое должно быть обновлено для 
поддержки кода МУС. Такая ситуация возникает, когда во время перехода на раз- 
работку в стиле МУС требуется постепенно переносить на зту платформу части 
существующего проекта. (Не всегда есть возможность переписать все с нуля.) 


Если вы оказались в одной из зтих двух ситуаций, значит, вам повезло. Несмотря на 
огромные концептуальные различия между двумя стилями разработки, общая базовая 
инфраструктура позволяет их очень легко интегрировать. Разумеется, существуют не- 
которые ограничения, о которых вы узнаете в зтой главе. 

Простейший снособ совместного использования АЗРМЕТ МУС и АЗРМЕТ \еБЕогтз 
состоит в том, чтобы включить проект веб-приложения МУС и отдельный проект 
М/еБЕогил$ в одно решение У151а!1 Эва 1о. Сделать это легко, но в результате получится 
два отдельных приложения. В настоящей главе рассматривается более совершенный 
подход: использование обеих технологий в рамках одного проекта для получения един- 
ственного приложения. 


На заметку! Для понимания материала зтой главы понадобятся базовые знания традиционной 
технологии АЗР.МЕТ \\МеБРогтл$. Если вы ранее не имели дела с МебРогтз, то можете спокойно 
пропустить эту главу, поскольку вряд ли у вас имеется какой-нибудь код \МеБРогтз для повтор- 
ного использования. 


Использование технологии 
МебРогт$ в приложении МУ\УС 


Периодически у разработчиков возникают веские причины для использования техно- 
логий УеБЕоги$ в приложении МУС. Например, может понадобиться использовать эле- 
мент управления, который доступен только в виде серверного элемента в стиле \еБЕогил$ 
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(сложный специальный элемент управления из раннего проекта \\еБЕогилз). Или, ска- 
жем, создается определенный зкран пользовательского интерфейса, для которого, как 
известно, \МеБЕогил$ предлагает более простую реализацию, чем АЗРМЕТ МУС. 


Использование элементов управления 
Ме Рогт$ в представлениях М\УС 


В некоторых случаях можно просто поместить существующий серверный злемент 
управления АЗРМЕТ на представление МУС. и он сразу будет работать. Это часто 
бывает с элементами, которые генерируют НТМЕ-разметку, но не выполняют обрат- 
ных отправок на сервер. Например, злемент управления <азр:51сеМарРафВ> или 
<азр:Вереафек>! очень легко использовать в шаблоне представления МУС. Если необ- 
ходимо установить свойства элемента управления или вызывать привязку данных для 
содержимого У1емраса, поместите в любое место страницы представления соответст- 
вующий блок <зсг1ре кипае="зегуег">, например: 


<зсг1ре гипас="зетуех"> 
ргобесбеб ухо14 Раде Тоа9(ою]есЕ зепдек, ЕуепфАтгдз е) 
{ 
МуВереа®ег.Рафабоигсе = Улеиафа ["рходис®з"]; 
МуВереае ег .РафаВ1та(); 
} 
</зсеарЕ> 


Формально можно было бы даже подключить элемент <азр:ВереаЕег> к элементу 
управления <азр:591Рабабоцгсе>, как это часто делалось в демонстрациях примене- 
ния \\еЕогглз$, но зто бы полностью противоречило принципу разделения ответствен- 
ности, поскольку игнорировались бы модели и контроллеры архитектуры МУС, сводя 
все приложение в дизайну в стиле Этац ЧТ (см. главу 3). В любом случае, использование 
элемента управления <азр : Вереаъег> в представлении МУС крайне маловероятно, так 
как простой цикл <$% Еогеась(...) %> выполняет работу более непосредственно, не ну- 
ждаясь в событии привязки данных, и обеспечивает при этом строго типизированный 
доступ к свойствам каждого элемента данных. Пример с <азр:Кереафех> был показан 
лишь для того, чтобы продемонстрировать, что привязка данных остается возможной. 

Но как насчет серверных элементов управления УеБЕогтз, которые получают ввод 
от пользователя и вызывают обратные отправки на сервер? Использовать их в проекте 
МУС намного сложнее. Даже если ввод сводится к простому щелчку на ссылке страницы, 
механизм обратной отправки будет работать только в том случае, если серверный эле- 
мент управления находится внутри формы \МеБЕогиз серверной стороны?. Например, 
если поместить элемент управления <азр : 6г19\1ем> в представление МУС, возникнет 
оптибка, показанная на рис. 16.1. 

Элемент управления Сг1Я\1ем отказывается работать вне формы серверной сто- 
роны, потому что зависит от механизмов обратной отнравки \еБРогитз и данных 
У1еибфате, которые лежат в основе иллюзии хранения состояния \еГоги1$. В АБРМЕТ 
МУС эти механизмы отсутствуют, поскольку платформа АЗРМЕТ МУС спроектирована 
для гармоничного взаимодействия (а не борьбы) с НТМЕ и НТТЕ 


* Подробные сведения об этом и других элементах управления \е5Еогтз ищите в книге 
Мэтью Мак-Дональда и Марио Пшпушты Мтозой АЗРМЕТ 3.5 с примерами на С# 2008 для 
профессионалов, 2-е издание (ИД “Вильямс”, 2008 г.). 


То есть в дескрипторе <Еотт> с атрибутом гопа®="зегуек". Это контейнер \е5Еогитз для 
логики обратной отправки и данных у1ем5{а\фе. 
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Рис. 16.1. Многие серверные злементы управления М/е6Рогтз работают внутри 
форм серверной стороны 


Было бы неразумно игнорировать принципы дизайна МУС, вводя механизмы 
Утембеасе и обратных отправок \/еБЕогт$, хотя теоретически это можно было бы сде- 
лать, например, поместив элемент Сг19У1е\ внутрь формы серверной стороны в шаб- 
лоне представления МУС, как показано ниже: 


<Еоги гиопас="5екуехг"> 
<азр:Сг19\У1ем 19="иубт19У1емСоп®ко1" гипаЕ="зекуех" /> 
</Еохи> 


После этого элемент управления Сг19У1еи визуализирует себя корректно, и, предпола- 
гая, что он будет привязан к некоторым данным, его события обратной отправки дейст- 
вительно будут работать (дополнительные требования для этого рассматриваются ниже). 
После установки соответствующих обработчиков событий Ст1ЧУ1ем посетитель сможет 
выполнять навигацию по многостраничной сетке, щелкая на ссылках для перехода на 
различные страницы. и изменять порядок сортировки, зцелкая на заголовках столбцов. 

Удалось ли при этом получить лучшее из двух технологий? К, сожалению, нет. 
Попьтка применения ориентированных на обратные отправки элементов управления 
У’еБЕогтз чревата возникновением ряда сложностей и проблем. 


® Платформа \еБЕогтаз разрешает иметь только одну форму серверной стороны на 
страницу (если попытаться создать их больше, генерируется опгибка). Поэтому 
нужно либо хранить все ориентированные на обратные отправки элементы 
управления в структуре страницы (тем самым ограничивая возможности компо- 
новки), либо копировать традиционную стратегию \еБЕогтз, помещая всю стра- 
ницу представления в единый дескриптор <Еоги гипас="зегуег">, возможно, 
на уровне мастер-страницы. Основная проблема описанной стратегии в том, что 
спецификация НТМГ, а вместе с ней и веб-браузеры не допускают вложения деск- 
рипторов <Еоги>, позтому вы лишаетесь возможности использовать другие деск- 
рипторы форм НТМГ, вызывающих другие методы действия. 


® Дескриптор <Еоги гипаз="зегуег"> генерирует большой объем иногда нестан- 
дартной НТМГ-разметки, добавляя печально известное скрытое поле _УТЕИЗТАТЕ, 
и даже может встраивать автоматически генерируемый код ДауаЗспрь, в зависи- 
мости от того, какие злементы управления \еБЕогтз помещены на форму сервер- 
ной стороны. 


® Обратные отправки уничтожают состояние любых отличных от \МеБРогтаз элементов 
управления. Например, если вшаблоне имеется дескриптор <%= Нет1 .ТехВох () %>, 
то его содержимое будет сброшено после обратной отправки. Именно поэтому нельзя 
применять отличные от \е Еогтп$ элементы управления с обратными отправками. 
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® Формы серверной стороны не могут быть использованы в сочетании с вызовами 
вспомогательного метода Нёи1.ВепдегРаг®1а1(). Если частичное представление 
присутствует в том же шаблоне представления, что и форма серверной стороны, лю- 
бая отправка приведет к генерации исключения “УаНАаНоп оЁ\Ле\5ае МАС Ёайеа” 
(Сбой проверки достоверности кода аутентификации У1ем5 $ а®е). Причина исключе- 
ния втом, что частичное представление само по себе является страницей \\еБЕогти®, 
и в ней неверно интерпретируется значение _ УТЕИЗТАТЕ, переданное в запросе. 


Использование страниц Ме Рогт$ в веб-приложении М\УС 


Если действительно необходимо использовать элемент управления \МеБЕоггл$ с об- 
ратными отправками, то надежное решение состоит в том, чтобы разместить элемент 
управления на реальной странице \еБЕогил$. На зтот раз не возникнет никаких техни- 
ческих сложностей, поскольку проект АЗРМЕТ МУС наряду со своими контроллерами и 
представлениями может включать в себя серверные страницы У/еБЕогга®. 

Добавьте страницу У\еБЕогилз к веб-приложению МУС в среде \1зиа1 Эва41о. Для этого 
щелкните правой кнопкой мыши на папке проекта в окне ЗоаНоп Ехр]огег, выберите в 
контекстном меню пункт Ада=> Мем/ Нет (Добавить->Новый элемент) и затем в соткрыв- 
шемся диалоговом окне АЧЯ Мем Нет (Добавить новый элемент) выберите \\еб Ропт 
(Веб-форма) в качестве шаблона (рис. 16.2). Страницы У\еБЕогл$ предпочтительнее 
хранить в специальной папке проекта, например, /ИеБкогиз. После этого постройте 
новую страницу \\еБЕогтаз в точности, как делали бы это в традиционном приложении 
АЗРМЕТ \еБЕогтпз, используя поверхность визуального конструктора У150а1 Эбаатю либо 
добавляя обработчики событий к классу отделенного кода. 

Когда запрашивается ОЕ, соответствующий файлу АЗРХ (например, /меБгогиз/ 
МуРаде.азрх), этот файл загружается и выполняется в точности как традиционный 
проект \еБЕоги$, поддерживающий обратные отправки. 

Естественно, эта страница не даст возможности воспользоваться всеми преимуще- 
ствами платформы МУС ЕгатемотК, но зато позволит разместить в себе любой сервер- 
ный злемент управления У\еБЕогиа$. 
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Рис. 16.2. Добавление веб-формы к веб-приложению М\УС производится очень просто 
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Добавление поддержки маршрутизации 
для страниц \ММебРогт$ 


При запросе страницы \еБЕогтл$ с использованием ОВГ, соответствующего ее фай- 
лу АЗРХ на диске, полностью обходится система маршрутизации, так как она отдает 
предпочтение файлам. которые действительно существуют на диске. Если же вместо 
обхода системы маршрутизации требуется интеграция с ней, то можно поступить так. 
как описано ниже. 


1. Получать доступ к страницам \\еБЕоггиз через чистые ОБТ, которые соответству- 
ют остальной части схемы ОВ. 


2. Использовать методы генерации исходящих ОВ! для перехода на страницы 
УеБЕогил$ с помощью ссылок и перенаправлений, которые автоматически обнов- 
ляются при изменении конфигурации маршрутизации. 


Как известно, болыпинство элементов Воите используют обработчик мусвонЕеНапа1ех 
для передачи управления от системы маршрутизации в МУС Егате\от!К. МусвопкеНап1ех 
требует параметра маршрутизации по имени сопёко!1ек, вызывающего соответствую- 
щий класс ТСопего11ег. Для страницы \еБЕогтз нужна какая-то альгернатива обра- 
ботчику МусвоцеНап]1ек, которой было бы известно, каким образом обнаруживать, 
компилировать и создавать экземпляры страниц \еБЕогииз. 

Ниже приведен пример подкласса Вопфе, который подходит для применения со 
страницами \МеБЕогтз. Ему известно, как использовать метод Ви119Мападех .Сгеаее 
ТизфапсеЕком\У1теца1РасВ() для обнаружения, компиляции и создания зкземпляра 
страницы У\еБРогт$. Кроме того, он не затрагивает генерацию исходящих ОБТ, кроме 
случая, когда специально передается параметр у1хЕча1РаЕВ, который соответствует 
ему самому. 

15119 бузсем.Мер.Сотр11ае1оп; 

риб1+1с с1азз МерЕГогизВоцее : Воцсе 

{ 

// В конструкторе жестко закодировано использование 
// специального обработчика МИеБКогизВоскеНапЯ1ех 
ру611с МерЕГогизВоц®е (56 у1п9 иг1, зЕх1па у1хбиа1Рафи) 
: Базе (цЕ1, пем ИебгохизВоц®еНап ет { У1гбиа1РафВ = у1уЕца1Рафь }); { } 


руб11с оуегг14е У1:хбоа1РаеЮраба Себ\У1уЕеца1РаЖр ( 
Веацез(СопеехЕ геацез®Соптехе, Воцфеуа1аерлсЕ1орату уа]щез) 
{ 
// Генерировать исходящий ОВ, только когда у1хбщца1Раеь 
// соответствует этому злементу 


5Е:1п9 раЕВ = ((МебгогизКоцЕеНап91ет) №15 .ВоцкеНапоТег) .\У1тЕиа1РаЪВ; 
1Е ((36:119) уа1аез ["у1гсца1РабВ"] != раеВ) 

тегаги пи11; 
е15е 


{ 
// Исключить у1гбиа1РаЕЬ из сгенерированного ОВГ, иначе будут 
// получаться ОВЬ вроде /зоше/ик1?у1укиа1Рафн=-/РаВ/Раде.азрх 
уаг уа]1аезЕхсер(\1тЕца1РаЕЪ = пем Воцееуа1иер1сЕ1опахту (уа1цез); 
уа1аезЕхсер®У1гЕпа1Ра®В .Ветоуе ("у1уЕца1РафЬ"); 
хебако разе.Сбеф\У1г{иа1Ра®В (хедиезСопЕехЕ, уа]пезЕхсерЕ\У1 теца1Ра®\); 


Глава 16. Комбинация платформ МУС и МебРогтз 541 


ргууабе с1азз МергогизВоцкеНап91етг : ТКоифеНапа1ег 
{ 
риб11с зЕг1па У1хроа1РаЕЪ { дее; зе®; } 
рую11с ТВЕЕрЕапд1ег беЕнНЕеЕрНапа1ет (КедиезЕСопеехЕ гедиезЕСопфехЕ) 
{ 
// Компилировать файл АЗРХ (если нужно} и создать экземпляр веб-формы 
гегигп (ТНЕЕрНапЯ1ег)Ви119Мападех .СгеафеТпапсеггон\У1теца1Раев 
(У1тЕоа1РаёВ, суреоЕ (ТНЕЕрНапа1ег))}; 


} 


После определения этого класса в любом месте проекта приложения МУС его можно 
использовать для настройки элементов Воосфе на страницы У’еЪЕогтз. Например, для 
страницы \еБЕогил$, расположенной в /Рафв/МуРаде-азрх, к методу Вед15егКоцсез () 
в СТора1.азах.сз можно было бы добавить следующий вызов. создающий новый эле- 
мент маршрута МерЕогизВоисе: 


гоисез.Ааа (пеи МебЕогизВоите ("зоте/иг1", "-/Ра /МуРаде.азрх")); 


На заметку! Поместите этот элемент (вместе с остальными ИергГогизВоиее) в начало конфи- 
гурации маршрутизации, перед обычными элементами маршрутов МУС. В противном случае 
обнаружится, например, что маршрут по умолчанию ({сопЕго11ег} / {асЕ1оп} / {1а}) пе- 
рекроет элемент маршрута ИефКогизВоите — как при сопоставлении с входящими ЦВЕ, так 
и при генерации исходящих ЦВЕ. 


Как и можно было ожидать, это раскроет -/РаЕв/МуРаде .азрх на ЧЁ! /зопе/иг1. 
Теперь также можно сгенерировать ссылки или перенаправления на этот элемент мар- 
птрута из представления МУС: 


<$= НЫ .Воиее!тлик ("С11сКк пе", пем { у1хбоа1РаёЬ = "-/Ра Ъ/МуРаде.азрх" }, пи11) %> 
или иэ контроллера МУС: 


ри6ю11с АсЕ1опВези1е Вед1гесеТомеьЕоги () 
{ 

териго Вед1гесЕТоВоифе (пем { у1хбаа1РаЕН = "-/Ра®/МуРаде.азрх" }); 
} 


или из обработчика событий отделенного кода страницы \еЪЕогтив: 


уо1а МуВиЕЕоп С11ск(оБ]есЕ зепает, ЕуепЕАгаз е) 

{ 
уаг иг1 = сееВоиЕ1т9а0те1 (пем { у1гбиа1РафВ = "-/РаЕБ/МуРаде.-азрх" }); 
Везропзе.Вед1тес® (иг1.\У1гЕпа1РаЕВ); 

} 


// Многократно используемый служебный метод (поскольку в МерЕоги$ 
// отсутствует встроенный АРТ-интерфейс маршрутизации} 
зфаф1с У1хкиа1Расьраба СеЕвооЕ1т90тх1 (об]есф уа1чез} 
{ 
уаг БЕЕрСопсехе = пем НЕЕрСопеехЕМгаррехт (НЕСрСопбехЕ.Сигтепт); 
уаг гс = пем ВедиезЕСопеехЕ (ВеерСопеехе, пеми Воцеерака()); 
тебсаги ВоисеТаБ1е.Войбез .беф\Улееца1Раев (гс, пем Воибе\уа1иаерлсЕтопагу (уа1ез}); 
} 


Во всех приведенных выше случаях браузер будет перенаправлен на сконфигуриро- 
ванный ОВ! (в данном примере — /зоце/иг1). 
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Передача параметров (и привязка модели) для страниц И/еБРогтз$ 


Полученную к этому моменту реализацию маршрутизации для \еБКогиз относительно 
легко развивать в дальнейшем. Например, если страницам \ЕБЕогиз необходимо передавать 
параметры в фигурных скобках либо привязывать любые свойства отделенного кода к вхо- 
дящей форме или значениям строки запроса, следует обновить код ИеБЕогизвонеенапа1ех, 
как показано ниже. (Работа кода привязки модели описана в главе 11.) 


рг1уабе с1азз МергогизВоиееНнап1ет : ТВосбеНнапа]1егк 
{ 
риу6ю11с зЕтг1па У1гЕиа1РаЕН { чеЕ; зет; } 
РУЮ11с ТЕЕЕрНапа1екг беЕне&рНапо1ет (ВечиезЕСопеехЕ гедиезСопеехь) 
{ 
// Компилировать файл АЗРХ (если нужно) и создать экземпляр веб-формы 
оресе раде = Ви119Мападег .СгеабетизбапсеЕкоп\1 гаа1РаЕь (У1геиа1Раев, 
СуреоЕ (ТНЕЕрНапа1ет))}; 
// привязать свойства, включенные с помощью атрибута [Взп@] страницы 
уаг БлпаАЕЕЕаЬаее = (ВапаАЕЕЕЗЬике) 
АСЕу1рафе .СееСа5ощАЕЕЕ1Ьиее (раде.СееТуре(), фуреоЕ (Вапалеек1Ьике)); 


Е (БарадЕектЬсЕе != пи11 && 1561109 .Т5Ма ПП ОкЕпреу (ЫралЕЕу1Ьиее . Тпс1аае) ) 
{ 
// Настроить контекст привязки модели 
уах @итуСопеко11ек = пеи РаттуСопЕко11ек (); 
уаг сх = пем СопЕго11екСопеех+ (кечиезСопеехе, ЯЧашиуСопеко11ег); 
ЗатиуСопего11ек.Сопего11ехСопфехЕ = сх; 
ТМоде1В1пЯек Ъзп4ег = Моде1В1паегз .Вап4егз .СееВап4ек (раде .СетТуре ()); 


// Выполнить привязку модели 
Ъ1пдек . В1п9МоЧде1 (сЕх, пем Моде1Вата1поСопфехе { 
МоЯе1 = раде, 
Мо4е1Туре = раде.СееТуре(), 
Уа1ТаеРкоу1Чег = ЧиттуСопеко11ег .Уа1еРкоу1Чек 
}); 
} 
тебиги (ТНЕЕрНапо1ег)рачде; 
} 
ргетуафе с1а55 РашпуСопеко]1ек : Сопёго]Лег {} // Используется для создания 
у // контекста привязки 
Предположим, например, что элемент маршрута имеет параметр в фигурных скоб- 
ках по имени РегзопМапе: 


гоп(ез .Ада(пем МерЕогизВоиее ("зоше/ит1/{РегзопМате}", "-/рап/МуРаде.азрх")); 


Теперь этот параметр маршрутизации можно привязать к общедостунному свойству 
РегзопМаце в классе отделенного кода, используя атрибут [В1п9]: 


[В1оа (Тпс1аЯе = "РегзопМапе") ] 
рУЮ11с рагЕ1а1 с1аз5 МуРаде : Зузбет.Мер.0т.Раде 
{ 
РУБ11с $&г1па РегзопМаше { деф; зе{; } 
рготесфеЯ уо01@а Раде Тоаа(оЮЗесЕ зеп4етх, ЕуепЕАгаз е) 
{ 
МутаБе1 .ТехЕ = РегзопМапе; 


} 
Это приведет к заполнению элемента управления Мурафе! в соответствие с входя- 
щим ОВ, как показано на рис. 16.3. 
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Рис. 16.3. Страница \\ебРопт$ в проекте МУС с параметром 
маршрутизации, привязанным к свойству страницы 


На заметку! Поскольку в этом коде используется средство привязки модели МУС, в нем также 
можно привязать входящие значения зЕг1па к произвольным типам свойств, включая 16, 
РафеТ1ме, коллекции и специальные типы. С целью безопасности привязка модели выполня- 
ется, только если в классе отделенного кода М/ебРотт$ применяется атрибут [В1п9] с исполь- 
зованием Тпс1аде="ргор1, ргор2, ..." для указания явного списка свойств, разделенных 
запятыми, которые будут заполняться через привязку (т.е. по умолчанию привязка произволь- 
ных свойств отделенного кода к значениями входной строки не производится). 


Примечание об авторизации на основе ЦВЕ 


И, наконец, имейте в виду, что если для управления доступом к страницам \еБЕогтз 
по определенным ОБТ, используется модуль От1ТАлВог1 хабтопМоаи1е из \еБЕогтлз, то 
правила авторизации должны быть добавлены также и к ОВГ, маршрутизации, а не 
только к путям файлов АЗРХ, которые обрабатывают зти ОВГ. 

Другими словами, если необходимо защитить страницу \еБЮгиз$, раскрытую с по- 
мощью следующего элементы маршрута: 


гоисез .Ааа (пем МерЕогизВойфе ("зоше/ит1/ {РегзопМане}", "-/РаЕВ/МуРаде.азрх"}); 


то авторизацию на основе ОНТ, не следует конфигурировать так, как показано ниже: 


<сопЕ1дагаЕ1оп> 
<1осаЕ1оп ра Н="РаВ/МуРаде.азрх"> 
<зузтеп.мер> 
<аицвог1хаЕ1оп> 
<а11ои го1ез="адили1 Е гаког"/> 
<депу изегз="*"/> 
</ацВот12ае1оп> 
</зузрет.мер> 
</1осафлоп> 
</сопЕ1дигаЕ1оп> 


Вместо этого она должна быть сконфигурирована следующим образом: 


<сопЁЕ1дигаЕ1оп> 
<1осафзоп раеЪ="зоме/ик1"> 
<зузсет.иер> 
<аиЕпог1хаЕ1оп> 
<а11ом го1ез="аа1ил:Егафок"/> 
<Чепу изегз="*"/> 
</аиеВог1хае1опт> 
</зузфет.мер> 
</1осаЕ1оп> 


544 Часть |. АЗРМЕТ МУС во всех деталях 


<1оса&1оп раёп="РаВ/МуРаде.азрх"> <!-- Предотвратить прямой доступ --> 
<зузбен.имер> 


<аиВог1хаф1оп> 
<аепу изегз="*"/> 
</апцЕВог1таЕ1оп> 
</зузЕен.мер> 
</1осаЕ1оп> 
</сопЕ1дига 1оп> 


Причина в том, что модуль Ог1АСЕНог1 га] опМоди1е учитывает только такие ОБТ, 
которые запрашивают посетители. Ему ничего не известно о файле АЗРХ, который в 
конечном итоге обработает запрос. 


Использование технологии АЗР.МЕТ МУС 
в приложении \М!еРогт$ 


Далеко не все программные проекты начинаются с чистого листа. Если вы ранее 
занимались веб-разработкой в „МЕТ, то высоки шансы, что вам придется расширять и 
совершенствовать какое-то существующее приложение У\еБЕоги$. Вовсе не обязательно 
отбрасывать его и сразу переходить к разработке в стиле МУС. Такое приложение можно 
“модернизировать” для поддержки АЗРМЕТ МУС, сохраняя старые страницы Ме Еогтаз. 
После этого можно приступить к построению новых средств с использованием приемов 
МУС, по очереди перенося старые части приложения на платформу МУС. 

Возможно, не стоит об этом напоминать, но все же не забудьте перед началом модер- 
низации создать резервную копию исходного кода проекта! 


Модернизация приложения А$Р.МЕТ 
М!еРогт$ для поддержки МУС 


Для начала потребуется обновить приложение, ориентировав его на версию МЕТ 
ЕгатлехмюогК 3.5. Выполните следующие шаги. 


1. Если существующее приложение АЗРМЕТ было построено с использованием \1зна] 
Эеа@ю „МЕТ, виа! Зла 2003 или \1зиа] Эблаю 2005, то при первом его откры- 
тии в \У1зпа! 50110 2008 будет предложено обновить его для поддержки \1впа] 
Эба@ о 2008. (Обратите внимание, что это означает невозможность в дальнейшем 
открывать проект в версиях, предшествующих \1зца]! Зрлаю 2008.) В данном слу- 
чае все просто. Нужно лишь следовать указаниям мастера. 


2. В Увца! Злаю поддерживаются два тина проектов \МеЬЕогтоз: веб-приложение, в 
котором есть папка \Ъ1п, файлы .дез1отег.сз и файл .сзрго1, и веб-сайт, ко- 
торый лишен всего этого. Если проект представляет собой веб-приложение, то все 
в порядке, и можно переходить к шагу 3. Но если проект является веб-сайтом, то 
прежде чем двигаться дальше, он должен быть преобразован в веб-приложение. 
Соответствующие инструкции доступны по адресу ВЕЕр: //мзап.и1скозотЕ . сош/ 
ти-го/11Югагу/аа983476.азрх. 


3. После открытия веб-приложения в \1 зна] Элато 2008 удостоверьтесь. что оно ори- 
ентировано на „МЕТ ЕгатехюотК 3.5. Для этого щелкните правой кнопкой мыши 
на имени проекта в окне ЗойаНоп Ехр]огег и выберите в контекстном меню пункт 
Ргорегйез (Свойства). В списке Тагде! ЕгатлемюгКк (Целевая платформа) на вкладке 
АррйсаНоп (Приложение) должен быть выбран вариант МЕТ РЕгатемсик 3.5, как 
показано на рис. 16.4. 


Глава 16. Комбинация платформ МУС и \МеьРогт$ 


Аррисаной” 


Вы 


АззеглЬу пагле 


Вы Езлвя : 
ариеБРоитзрр 

Весы 
Фапрее Реанлемси в: 

Ея т 
НЕТ Еевилечис 

И 

Зато ® 


бах 
ВЧ 


545 


Рис. 16.4. Переключение проекта на целевую платформу .МЕТ Ргатемюгк 3.5 


После переключения проекта на платформу „МЕТ ЕгатехюогК 3.5 убедитесь, что при- 
ложение по-прежнему нормально компилируется и корректно выполняется. Поддержка 
обратной совместимости в МЕТ достаточно хороша, так что проблем возникать не 


должно (по крайней мере, теоретически). 
Затем необходимо добавить к проекту сборки АЗРМЕТ МУС. 
Выполните перечисленные ниже шаги. 


1. Добавьте в проект ссылки на сборки Зузеен.Меь .Мус, 
сузкеш.Меь.АБзегасЕ1отз и бузкем. Ме .ВоЕ1п03. 
Если планируется использовать М1скозоЕЕ . Мер .Мус 
(сборку МУС Еифагез}, добавьте ссылку и на нее. 


2. В окне Зой1Ноп Ехрогег среды \У!зиа! 560 раскройте 
список НеГегепсе$ (Ссылки) проекта, выделите три сбор- 
ки, для которых были только что добавлены ссылки, и в 
панели Ргореге$ (Свойства) убедитесь, что для свойст- 
ва Сору 1оса! (Копировать локально} установлено значе- 
ние Тгие (рис. 16.5.). В результате выделенные сборки 
будут скопированы в папку \Ъ1п приложения при его 
компиляции. 


Теперь можно включить и сконфигурировать систему мар- 
шрутизации. Выполните следующие шаги. 


Зояюл ЕхрЮгег- Зоо вы = Я Х 


ЕЁ ЕМеля он.» 
и =БЫсЬе 


о 


Зузегт МЕБ. ЗЕРАСЕ: 


Рис. 16.5. Настройка 
копирования сборок МУС 
в папку \©1п приложения 


1. Если приложение пока еще не имеет файла С1ора1.азах, добавьте его. Для этого 
щелкните правой кнопкой мыши на имени проекта в окне ЗовлЧоп Ехрогег, выбе- 
рите в контекстном меню пункт АДа=>Мем! Нет (Добавить=>Новый элемент} и затем 
в открывшемся диалоговом окне АЯЯ Мем/ Пет (Добавить новый элемент) выбери- 
те СюБа! Аррйсайоп С!а$$ (Глобальный класс приложения) в качестве шаблона. 
Для него можно оставить имя, предлагаемое по умолчанию — С1ора1.азах. 


2. Перейдите к классу отделенного кода в файле С1ора1 .азах (щелкнув на нем пра- 
вой кнопкой мыши и выбрав в контекстном меню пункт \Ме\м/ Соде (Просмотреть 
код) и добавьге показанный ниже код, чтобы сделать его таким же, как в файле 


С1ора1.азах.с$ из приложения АЗРМЕТ МУС: 


151109 бузеет.Меь.Мус; 

и51па бузЕет.Меь.ВойЕ1та; 

ру611с с1азз С61ора1 : Зузеем. Мер .НЕЕрАрр11саЕ1оп 
{ 


3 Все зти сборки можно найти на вкладке .МЕТ окна Ада Вегегепсе (Добавить ссылку). 
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ргофесфей уота Арр11саЕ1оп_ 5$агь (оБ]ес® зепдек, ЕуептАгоз е} 
Вед15+ехВоцеез (ВоифеТаьЬ1е.Воцфез); 
а зЕаф1с уо1а Вед15етгВоцеез (ВочфеСо11ес1оп гкоцеез) 
. хоцфе5 .ТдпохевоцЕе ("{хгезоцгсе}.аха/ { *рафЬтТрЕо}"); 
гоцфе$ .МарКоцее ( 


"РеЕаа1*", // имя 
"{сопЕго11ех} / {ас1оп}/{1а}", // овь 
рем { асЕ1зоп = "Тоаех", 1а = "" } // Установки по умолчанию 


); 
} 
// Остальной код не изменяется 


} 


Обратите внимание, что в этой конфигурации маршрутизации не определено зна- 
чение по умолчанию для сопего11ег. Это удобно, когда необходимо, чтобы кор- 
невой ЧВГ (те. -/) отображал страницу \ЕЪЕогиоз по умолчанию - /аеЕас1е.а зрх 
(а не действие Тпдех контроллера НомеСопЕго11ех). 


3. Активизируйте модуль Ог1ВБочЕ1поМоао1е, добавив в файл мер.сопЕ1а узлы 
<ВЕЕрМодо1ез> и <зузсеи.иею5егуег>: 


<сопЕ1диагаЕ1оп> 
<зузтен.мер> 
<ВЕЕрМоа1е$> 
<а9а паше="Ок1Воие1п9Моди1е" 
фуре="Зузфет.МеЬ .ВочЕ1па .Охк1Воче1паМоди1е, ЗузЕет.МеЪь .ВочЕ10а"/> 
</ВЕЕрМоан1ез> 
</зузЕет.мер> 


<!-- Следующий раздел необходим для развертывания на сервере ТТ$ 7 --> 
<зузЕеи.мпербегуег> 
<уа11АаЕ1оп уа11Часетпфедгаке МодесопЕ1сигак1оп="Еа1зе"/> 
<ио@и1ез$ гипА11МападеЯМоди1е ЕогА11Ведаезез="егие"> 
<гепоуе паме="Ок1БопЕ109Моди1е"/> 
<ааа папе="Ок1Вопе1п9Модио1е" 
Еуре="Зузфеп.Меь .ВоцЕ1п9 .Охк1ВоцЕ1п9Мофа1е, бузЕет.Меь.Воцета" /> 
</поао1ез> 
<ВапЯ1егз> 
<аЧ4 паме="Ох1БоцЕ1пдНап@1ехк" ргеСопЯ11оп="1пееадкафеЯМоде" уекь="*" 
ра="Ок1Воз1 па .аха" 
туре="Зузфет.МеЪ . НЕЕрЕохЬ1Я4епНапЯ1ех, Зузфет.Меь"/> 
</Вап1егз> 
</зузеем.иербегуег> 
</сопЕ1дикае1оп> 


Теперь имеется работающая система маршрутизации. Она не будет мешать запро- 
сам, адресованным непосредственно к существующим страницам *.азрх, поскольку 
по умолчанию маршрутизация отдает предпочтение файлам. реально существующим 
на диске. Чтобы проверить корректность функционирования системы маршрутизапии. 
потребуется добавить как минимум один контроллер МУС. Выполните перечисленные 
ниже шаги. 


1. Создайте новую папку верхнего уровня под названием Сопего11егз и добавьге в 
нее простой класс С# по имени НошеСоп+го11 ет: 
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3119 бузвет.Мер.Мус; 
ру611с с1азз НошеСопего11ег : Сопёго11ег 


{ 
руБ11с АсЕ1опКези1е Тпаех () 


{ 
} 


гебагп Улем(); 


} 


. Если теперь перекомпилировать проект и зайти на /Ноте, новый контроллер бу- 
дет выэван и попытается визуализировать представление. Поскольку представле- 
ние не существует, отобразится сообщение об ошибке, показанное на рис. 16.6. 


. Чтобы устранить оптибку, создайте еще одну папку верхнего уровня \1е\5, а внутри 
нее дочернюю папку Нопе. Щелкните правой кнопкой мыши на папке Нопе, выбери- 
те в контекстном меню пункт АЧЧ=>Меми Нет (Добавить=>Новый элемент) и создайте 
веб-форму по имени Тпаех .азрх. (Обратите внимание, что У1зпа1 Эызю пока не дает 
возможности создать страницу представления МУС, но это скоро будет исправлено.} 


. Перейдите к классу отделенного кода новой веб-формы (щелкнув на ней правой 
кнопкой мыши и выбрав в контекстном меню пункт \е\м/ Собе (Просмотреть код) 
или нажав <Е7>) и замените базовый класс бузеет.Мер.ОТ.Раде на Зузфеп. мер. 
Мус.У1еиРаде. 


. Вернитесь к представлению разметки Тпдех .азрх. удалите форму серверной сто- 
роны (те. дескриптор <Еоги> с атрибутом гопае=" зегуег") и добавьте к пред- 
ставлению какое-то другое содержимое по своему выбору. Обратите внимание, 
что прежде чем можно будет пользоваться вспомогательными методами НТМГ. из 
АЗРМЕТ МУС (например, <%= Нет1.* %>), в файл иер.сопЕ19 необходимо доба- 
вить следующий узел <памезрасез>: 


<зузвеш.мею> 
<радез> 
<пашезрасез> 
<а@а патезрасе="бузем.Иеь.Мус" /> 
<а@а патезрасе="буз®ет.Меь .Мус.Адах"/> 
«ааа патезрасе=" бузфет.МеЪ .Мус.Ни1" /> 
<ааа патезрасе="бузфет.МеЪь .Боц&1па"/> 
<а@а патезрасе="буз+ет. 104" /> 
«аа папезрасе="ЗузЕет.Со11есЕ1оп5 .бепех1с"/> 
</патезрасез> 
</радез> 
</зузрет.мер> 


{| 1 Тое ем моек ог й$ пчазвеЕ сс в 


5. 4 г. Ир: Лосайноя 83651. = 
о лото ранен реет мл, 


| тре маи Тодех' ог Из тазёег соша поЁ ре Гоипд. | 
2 тре ЮНомта юсавоп$ уеге зеагсред: | 
илеиж/Ноте/таех.азрх 

5 Имеиз/Ноте/тдех.азсх 

| оИмМемз/звагед/Ттаех.аярх 

Г «Имеамз/срагед/таех.азсх 


БезсгУНо: Ал иввас 2 ехоесвоп сосмтея виа е ехесиюл ое сотгаг злеб гезиеяй - 


1 
ава 


Рис. 16.6. Такое сообщение об ошибке АЗРМЕТ МУС 
означает, что вы на верном пути 
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Теперь можно вновь посетить /Нопе и увидеть визуализированный шаблон прелд- 
ставления, показанный на рис. 16.7. 


Рис. 16.7. Проект \МебРоитз теперь также является проектом МУС 


Вот в основном и все! Проект \ебРоги1$ должен продолжать нормально работать при 
посещении любой из существующих страниц .азрх (поскольку файлы на диске имеют 
приоритет перед маршрутизацией). Кроме того, можно также добавлять контроллеры и 
представления и конфигурировать маршрутизацию в точности так, как это делается в 
приложении АЗРМЕТ МУС. 

После модернизации проекта \еБКогтз для поддержки МУС вы оказываетесь в той 
же ситуации, как если бы начали новый проект МУС и затем добавили целый набор 
страниц \еЪРогиз. Это означает, например, что если необходима поддержка маршру- 
тизации для страниц \/еЕогтз (вместо использования ОВГ, соответствующих их дис- 
ковым путям), то можно следовать советам. приведенным ранее в разделе “Добавление 
поддержки маритрутизации для страниц У\еБЕогилз” настоящей главы. 


Доступ к элементам МУС в среде Миа! Зиаю 


Между “родным” проектом веб-приложения МУС и “обновленным” проектом 
УМ’еБЕогтз имеется только одно отличие. При добавлении шаблона представления через 
диалоговое окно АОЯ Ме\м/ Нет (Добавить новый элемент) среда \1зиа] Зла не предос- 
тавит возможности выбрать МУС \Яе\’ Рабе или любой другой специфичный для МУС 
элемент. Точно так же после щелка правой кнопкой мыши внутри метода действия не 
будет возможности добавить представление. Причина в том, что среде У\1зпа1 Эыа1ю 
просто не известно, что вы имеете дело с проектом АЗР.МЕТ МУС. Вот почему описан- 
ном выше на шаге 3 (при добавлении представления для действия Тпдех контроллера 
НомеСопего11ет) необходимо использовать страницу \еБЕогт$ и изменять ее базовый 
класс вручную. 

Чтобы решить данную проблему. потребуется добавить подсказку о пите проекта 
для виа] Эл. 


Внимание! Перед тем, как двигаться дальше, создайте резервную копию файла проекта (файла с 
расширением .сзрго)) или, по крайней мере, удостоверьтесь, что в системе управления вер- 
сиями зарегистрирована последняя его копия. Дело в том, что если в зтот файл будут внесены 
ошибки, то \Мзиа! Зшаю не сможет открыть его. 


1. В окне Зош@оп Ехр]огег щелкните правой кнопкой мыши на имени проекта и вы- 
берите в контекстном меню пункт Уптоаа Ргодесе (Выгрузить проекз). 


2. Еще раз щелкните правой кнопкой мыши на имени проекта и выберите в контек- 
стном меню пункт ЕЧй МойПроект.сзрго} (Редактировать МойПроект.сзрго]). 

3. Откроется ХМГ-файл .сзрго]. Найдите узел <Рго} есЕТуреби1а$>, содержащий 
разделенную точками с запятой последовательность идентификаторов СОШ, и 
добавьте в него следующее значение перед всеми существующими: 
{603с0е0Ъ-9556-11ас-Ъе95-000956107950}; 
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Не добавляйте никаких дополнительных пробелов или переносов строки. Если не 
хотите вводить идентификатор СОТ вручную, можете скопировать и вставить его 
из соответствующего раздела любого готового файла АЗРМЕТ МУС „.сзрго). 


4. Сохраните обновленный файл .сзрго). Затем перезагрузите проект, щелкнув 
правой кнопкой мыши на его имени в окне Зо оп Ехрюгег и выбрав в контекст- 
ном меню пункт Неюаа Ргоест (Перезагрузить проект). 


Если будет получена ошибка “ТЬ1з ргодес: фуре 1$ поЁ зирроцеа Бу #513 шзаПаНоп“ 
(Данный тип проекта не поддерживается этой установкой), просто щелкните на 
кнопке ОК и выберите снова пункт Неюаа Ргоес{, как было описано выше. По 
какой-то причине это помогает ретить проблему ошибки. 


После этого специфичные для МУС элементы появятся в диалоговом окне АДА Ме\м 
Кеп наряду с обычными элементами У’еБЕоглз. Вдобавок появится возможность вы- 
полнять щелчок правой кнопкой мыши внутри метода действия и выбирать в контек- 
стном меню пункт Ада \Лем/ (Добавить представление). 


Взаимодействие между страницами 
\МеБРогт$ и контроллерами М\УС 


Чтобы выполнить перенаправление со страницы У Еопиз на действие МУС (без 
жесткого кодирования ОКП) необходимо добавить собственный служебный метод гене- 
рации ЧВГ, например: 


рготесфеа уо1а Раде Гоа@(ою}]есЕе зеп@ег, ЕуепЕАгаз е) 
{ 

Везропзе .КеЯ1гесЕ (беЕВоце1па0т1 (пем { 

сопего11ег = "Ноше", асё1оп = "Траех" 

}) .У1геча1рРафВ); 
} 
// Многократно используемый служебный метод (поскольку в МеЬБЕогтз 
// отсутствует встроенный АРТ-интерфейс маршрутизации) 
руБ11с зфаф1с У1хфаа1РаЕВРафа СеЕВол1п90т1 (оБ]есе уа14аез) 


{ 
уаг НЕЕрСопфехе = пем НЕЕрСопфехЕИгаррекг (НЕЕрСопфехе .Сигхкепр®); 
уаг гс = пем ВеслезЕСопеех+ (ВЕЕрСопЕехе, пеи Воцферафа()); 
тебатп КоафеТаБ1е .Кочфез .Се{\У1тЕаа1РафЪ (гс, 
преим ВочфеУаГаер1сЕ1опаку (уа1ез)); 


} 


Применять вспомогательные методы <%= Еи1.* %> на страницах У\еБЕогтиа$ нельзя, 
так как бузеет.Мер.Чт.Раде не имеет свойства типа Нып1Не1рег (поскольку это свой- 
ство Зузтет.Мер .Мус .У1емРасде). Это нормально, потому что на странице \еЪЕогтиз все 
равно не удастся использовать, например, НЕп1 .ТехеВох() — вспомогательные методы 
НТМГ из МУС не работают вместе с обратными отправками. 

Но если необходимо установить ссылку со страницы \еБЮюплз на действие МУС, по- 
надобится некоторая замена методу НЕп1.Асе1опЬ пк (). Найдите в проекте подходя- 
щее место и раскройте ранее показанный метод СееКочЕ1п90т1 () как общедоступный 
статический метод. После этого его можно использовать на АЗРХ-странице \МеЕоптз: 


<а пгеЁ="<%= СлужебныеМетоды. сесВопе1па0т1 (пем { 
сопЕго11ег = "Нопе" }).Утгсоаа1РаЕВ %>"> 
1516 Ее тпаех асе1оп оп НомеСсопего11ег 
</а> 
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Передача данных между МУС и ИеБРогт$ 


Обе эти технологии построены на базе одной и той же платформы АЗРМЕТ. так 
что когда они обе сочетаются в одном приложении, то разделяют одни и те же коллек- 
ции 5еззтоп и Арр11саё1оп (помимо прочих). Для разделения данных между МУС и 
\еЪЕогиа$ также возможно, хотя и не просто, использовать Тепррака. Доступные вари- 
анты более подробно объясняются в табл. 16.1. 


Таблица 16.1. Варианты разделения данных между контроллерами МУС 
и страницами Ме ЬРогт$ в одном приложении 


оступ из Доступ со страницы 
Коллекция Использование д 

к у контроллера МУС — \МебРогт$ 

безз1о0п Для сохранения данных на время Зе5510п бе531оп 


жизни сеанса браузера индивиду- 
ального посетителя. 


Арр11сае1оп Для сохранения данных на время НЕеерСоптехе. Арр11саб1оп 
жизни всего приложения (и со- Арр11са&1оп 
вместного использования во всех 
сеансах браузеров). 

Тепрра® а Для сохранения данных в рамках Тешрраса Объяснения даны ниже 


одиночной переадресации в теку- 


щем сеансе браузера посетителя. 
Е Е Е 


Понятие “временных данных” появилось позже технологии АЗРМЕТ У’еЬЕогта$, по- 
этому в \еБРогтиз не предусмотрено простого способа доступа к ним, хотя доступ к ним 
возможен. Для этого придется написать собственный код извлечения коллекции из ле- 
жащего в основе хранилища. В следующем примере показано, как создать альтернатив- 
ный базовый класс Раде, который раскрывает коллекцию по имени Тепрака, загружая 
ее содержимое в начале запроса и сохраняя в конце: 


РУБ11с с1аз5 ТепррафаАмагеРаде : Зузфет.Мер.0Т.Раде 
{ 
ргобесёеЯ геааоп1Ту Тетррафар1сЕ1опагу Тетррафа = пем Тепррафар1сЕ1опагу (); 
ргофесЕеа оуегг1@е уо1@ ОпТо1е (ЕуепЕАгоаз е} { 
фазе. ОпТо1еЕ (е}; 
Тешррафа .Гоаа (беериттуСопеех* (}, пе Зеззтопб фа еТетррРаеаРгоу1@9ех ()); 


ргофесееЯ оуегг14е уо1а ОпОп1оаа (ЕуепкАгаз е} { 
Тепррафка .Зауе (беЕРиттуСопеехе (), пе Зезз1опбтаееТетррРа& аРто\19ехт ()); 
разе.Оп0Оп1оаа (е); 
} 
// Предоставить контекст, достаточный для загрузки и сохранения ТепрПафта 
руфлуафе звае1с Сопфего11ехгСопеехЕ сееритмуСоптехь (} 
{ 
гееигп пем СорЕго11егСоптехе ( 
пеи ВЕСрСоптехЕМгаррег (НЕЕрСопбехе .Сиггеп{), 
пея Восберафа(), 
_ антмуСопЕ го11етТизфапсе 
); 
} 
// Просто удовлетворить требование Гепрраха.Тоа@() к объекту контроллера 
рглуабе зваЁ1с Сопёго11ехг _ЧаитуСопего11ехтТизфапсе = пем РапшуСопего1Тех (); 
ргфуаее с1азз РамтуСопЕго11етг : Сопеко]1Лех { } 
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На заметку! В приведенном выше примере кода предполагается использование поставщика по 
умолчанию Зезз1оп5сасеТетрра&аРгоу1Аех, который хранит содержимое Тепррафа 
в коллекции Зезз1оп. В случае применения другого поставщика соответствующим образом 
скорректируйте код. 


Если теперь унаследовать страницы \МеЪЕогп1$ от ТетрракаАмагеРаде вместо 
Зузбем.Меь.ОТ.Раде, можно получить доступ к полю по имени Тепррака, которое ве- 
дет себя в точности так же, как коллекция Тепррака из МУС, и фактически разделя- 
ет те же самые данные. Если вы предпочитаете не менять базовый класс для страниц 
УМ\еБ Роги, то можете воспользоваться предыдущим примером кода в качестве отправ- 
ной точки и создать служебный класс для ручной загрузки и сохранения ТепрПака на 
странице У\еБЕогилз. 


Резюме 


В этой главе было показано, что несмотря на то, что платформы МУС Егате\могК и 
АЗРМЕТ \е Еогтз выглядят совершенно разными с точки зрения разработчика. лежа- 
щие в их основе технологии во многом пересекаются, поэтому они могут легко сосуще- 
ствовать в рамках одного проекта .МЕТ. 

Можно начать с проекта МУС и добавлять страницы У еБРогиз, дополнительно ин- 
тегрируя их в систему маршрутизации. Или же можно начать с проекта У’еЕогил$ и 
добавлять к нему средства МУС; вдобавок это еще и весьма жизнеспособная стратегия 
для переноса существующих приложений \\е Еогил$ на платформу АЗРМЕТ МУС. 
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